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ABSTRACT 


Modem  military  air  vehicles  have  to  comply  with  sophisticated  performance  requirements.  As  a  result,  full  advantage 
must  be  taken  of  the  rapid  advances  in  computer  hardware/software  and  future  micro-electronics  technologies. 

New  design  and  development  strategies  must  be  implemented  in  order  to  obtain  the  overall  performance  benefits  offered 
by  advanced  integrated  systems  for  guidance  and  control,  avionics,  weapon  delivery  and  tactical  performance  management. 

In  a  two-day  programme  this  Lecture  Series  will  address  some  issues  which  have  demonstrated  notable  and  outstanding 
advances  in  the  field  of  computing  system  design,  design  tool s  and  techniques,  computers,  data  buses,  and  architectures.  In 
particular,  the  second  day’s  programme  will  show  how  technological  advances  have  enabled  the  design  of  a  modem  computing 
system  architecture.  Future  trends  and  new  directions  will  be  subjects  for  round  table  discussions. 

This  Lecture  Series,  sponsored  by  the  Guidance  and  Control  Panel  of  AGARD,  has  been  implemented  by  the  Consultant 
and  Exchange  Programme  of  AGARD. 


Les  aeronefs  de  combat  modemes  doivent  repondre  a  des  specifications  de  performances  sophistiquees.  H  importe  done, 
de  tirer  le  meiileur  parti  de  la  rapidite  des  progres  realises  dans  les  domaines  des  materiels  et  des  logiciels  d’ordinateurs  et  des 
technologies  d’avenir  de  la  micro-electronique. 

II  y  a  lieu  de  tenir  compte  des  nouvelles  strategies  d'etude  et  de  realisation,  qui  permettent  de  beneficier  des  avantages 
offerts,  en  termes  de  performances  generates,  par  les  nou veaux  systemes  integres  de  guidage  et  de  pilotage;  d'avionique  et  de  tir 
d’armes,  ainsi  que  par  les  systemes  de  gestion  des  performances  tactiques. 

Les  deux  joumees  de  ce  Cycle  de  conferences  sont  consacrees  a  I'examen  de  certains  secteurs  ou  des  progres 
remarquables  et  exceptionnels  ont  ete  realises  dans  le  domaine  de  (a  conception  des  systemes  informatiquc.s,  a  savoir:  les 
techniques  et  les  aides  a  la  conception;  les  ordinateurs,  les  chaines  de  donnees  et  les  architectures.  En  particulier.  les 
presentations  de  la  deuxieme  joumee  concement  les  progres  technologiques  qui  ont  permis  la  realisation  d'unc  architecture  de 
systeme  informatique  modeme.  Les  tendances  et  les  perspectives  d’avenir  feront  I’objet  d’une  table  ronde. 

Ce  Cycle  de  conferences  est  presente  dans  Je  cadre  du  programme  des  consultants  et  des  echanges,  sous  I’egide  du  Panel 
AGARD  du  Guidage  et  du  Pilotage. 
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OVERVIEW  AND  INTRODUCTION 
TO  GCP  LECTURE  SERIES  NO  1 58  ON 
"COMPUTING  SYSTEM  CONFIGURATION  FOR  HIGHLY  INTEGRATED 
GUIDANCE  AND  CONTROL  SYSTEMS" 


IPA  L.  GUIBERT 

Service  technique  de<  Telecommunication  et  da  Equipanaits 
aeronautiqua 
1 29,  me  de  la  Convention 
75731  PARIS  CEDEX  15  .  FRANCE 


ABSTRACT 

The  avionics  of  modem  aircraft  are  increasingly  complex  and  perform  an  increasing  amount  of  functions. 
As  a  result,  configuration  problems  are  assuming  ever  greater  importance. 

We  should  first  define  what  we  mean  by  system  configuration.  Once  we  start  to  do  this,  it  becomes  clear 
that  because  of  the  integration  of  functions  It  1s  impossible  to  Isolate  guidance  and  control  systems  if  it  is  their 
architecture  we  are  Interested  In. 

Architecture  concents  both  equipment  and  systems  or  functions,  which  today  include  software,  and  this 
explains  the  variety  of  topics  which  will  be  dealt  with  in  the  papers  to  be  given:  design  aids  and  methods, 
computers,  data  buses  and  software  aids. 

It  is  perhaps  advisable  to  make  a  distinction  between  the  functional  architecture  and  the  physical  architecture 
of  an  aircraft.  Given  their  importance  and  their  effect  on  performance,  reliability,  survivability,  maintainability  and 
casts,  and  considering  the  complexity  of  the  problems  attaching  to  them,  their  design  requires  specific  facilities 

The  "Direction  da  Construction  Aeronautiqua"  ha  joined  forces  with  eight  French  companies  to  provide 
the  aeronautics  industry  with  an  Integrated  workshop  for  the  design  of  avionics  systems.  A  brief  description  of  the 
project  is  given. 


INTRODUCTION 

Fighter  aircraft  have  to  face  an  ever  growing  threat,  both  in  terms  of  quantity  and  quality,  on  the  ground  as 
well  as  in  the  air,  and  probably  shortly  in  space,  fn  order  to  meet  that  threat,  they  are  required  to  fulfil  more  and 
more  functions  under  increasingly  difficult  conditions,  while  achieving  ever  higher  performances. 

As  a  result,  aircraft  acquisition  and  user  cost  continue  to  grow.  Thus,  in  order  to  ensure  the  cost- 
effectiveness  oftnew  aircraft  development,  and  because  it  has  become  difficult  to  financially  support  several 
programs,  a  trend  towards  the  design  multi  role  aircraft  ha  recently  increased. 

The  logical  outcome  Is  s  further  increase  in  the  amount  a..„  „ciMexity  of  the  functions 
demanded . 

All  this  is  particularly  true  in  avionics  and  weapon  systems,  which  now  handle  the  essential  of  the  functions 
of  an  aircraft. 

Tlaii,  die  acquisition  cos t  of  avionics  (taken  to  its  broadest  sense  to  mean  everything  electronic  in  the  plane) 
whose  weight  represents  a  fairly  constant  one  tenth  of  tile  total  empty  weight  of  the  aircraft,  continue*  to 
increaae  in  proportion  to  the  overall  coat,  up  to  about  40%  for  next  generation  fighter  aircraft,  whereas  its 
maintenance  coat  can  form  up  to  80%  of  the  overall  one. 


IBEXQNCEPT  OF  CONFIGURATION 

That  is  the  framework.  In  this  context,  what  then  is  the  part  played  by  the  computing  system  configuration 
of  guidance  sod  control  systems? 

First  we  need  to  define  what  tint  expression  mens. 

Taking  the  shove  mentioned  constraints  and  needs  into  account  leads  to  an  imbrication  of  the  various 
functions  performed  by  today’s  navigation  and  weapon  systems. 

The  guidance  of  an  aircraft,  for  instance,  la  involved  to  all  stages  of  the  mission,  whatever  it  is,  and  must 
process  data  supplied  by  amonotnous  sensors  (Inertial  units,  terrain  data  memoria, ...),  radio-navigation  units 
(GPS,  ...),  tire  radar  (terrain  profila,  location  of  targets,  ...),  the  electronic  counter-measures  (for  threat 
avoidance),  or  by  the  system  Itself  (mission  planning,  tactical  data, ...),  etc. 

This  meshing  of  functions,  which  is  necessary  to  order  to  keep  avionics  within  reasocmable  volume  and 
coat  limits,  and  made  poaslbie  by  advances  to  mtcroetoctrooia  technology,  leads  to  the  withdrawal  of  the  concept  of 
sub-system. 
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Avionics  can,  in  fact,  be  divided  into  sensors,  core  computing  and  terminals  (mainly  displays,  controls  or 
actuators).  This  does  not  necessarily  mean  that  the  system  is  centralized:  core  computing  architecture  may  be  spread, 
with  certain  processors  remaining  physically  close  to  sensors  or  terminals.  However,  the  whole  core  takes  part  in 
processing  the  data  supplied  by  the  sensors,  and  in  generating  those  ones  sent  to  die  terminals. 

The  computing  configuration  of  guidance  and  control  systems  cannot  therefore  easily  be  dissociated  from 
the  core  avionics  computing  configuration,  and  this  will  be  ever  more  true  in  the  future,  as  we  shall  see  from  some 
of  the  lectures. 

To  simplify,  computing  systems  are  essentially  composed  with  computers  or  processors,  which  are 
organized  in  such  a  way  as  to  support  functions,  which  are  performed  by  software. 

The  configuration  problems  of  such  systems  thus  involve  the  design  and  definition  of  the  computers,  the 
overall  organisation,  or  more  precisely,  the  architecture,  and  the  way  in  which  the  software  is  designed,  using 
which  tools  and  methodology. 


OVERVIEW  OS  THE  LECTURES 

As  you  can  see,  the  subject  is  vast.  However,  1  thought  that  we  should  attempt  to  deal  with  each  area, not, 
of  course,  in  exhaustive  manner,  but  by  choosing  certain  important  topics,  so  that  the  lectures  will  show  the  way 
things  are  evolving  and  identify  the  keys  to  the  future,  because  it  seems  important  to  me  to  understand  that  all  these 
aspects  are  linked,  are  parts  of  a  whole. 

Thus,  the  first  lecture  by  Mr  H.  J.  KAUL  will  deal  with  the  question  of  flight  control  system  design,  and 
will  describe  tools  in  relation  to  a  method. 

We  shall  then  go  on  to  look  at  signal  and  data  processors  (hiring  the  lectures  by  Mr  M.  T.  MICHAEL  and 
Mr  M.  MUENIER,  in  particular  the  Common  Signal  Processor,  the  1750  A  standard  and  a  new  high  level 
processor,  the  CMF.  Perhaps  will  they  allow  us  to  raise  some  traditional  questions,  such  as  should  computers  be 
standardized,  will  32  bits  supplant  1 6  bits,  which  instruction  set  (RISC  or  not  RISC)? 

The  data  buses,  essential  element  of  connection  between  tbe  components  of  current  systems,  and  from 
which  considerable  performance  improvements  are  required  for  future  systems,  will  be  the  subject  of  the  lecture 
given  by  Mr  R.  UHLHORN  ,  who  will  particularly  address  the  subject  of  high  speed  optical  buses. 

We  shall,  of  course,  talk  about  software.  It’s  a  fundamental  part  of  the  system,  and  gives  it  life.  Its  volume 
is  exponentially  growing,  as  are  the  problems  attaching  to  it.  On  existing  aircraft,  we  can  consider  that  the 
acquisition  cost  of  the  software  for  the  central  computer  is  half  that  of  the  computers  themselves.  But  in  operation, 
that  ratio  may  reach  80%  of  die  maintenance  costs. 

As  future  aircraft  will  include  several  million  code  liaes,  software  quality  and  productivity  are  vital.  Mr 
MUENIER  will  describe  a  tool  for  software  testing,  as  part  of  a  workshop  about  which  I  shall  be  giving  you 
further  informations  later  on. 

We  shall  finally  tackle  the  problems  of  avionics  architecture  with  tbe  lectures  given  by  Mr  J.  C. 
OSTGAARD  and  Mr  D.  R.  MORGAN  on  PAVE  PILLAR.  These  statements  will  show  how  important  this  subject 
is,  both  in  terms  of  its  implications  for  avionics  system  design,  and  its  effect  on  performance  and  costs. 


1HE  RQ.LE.QF  ARCHITECTURE 

The  STANAG  3908  (Edition  1)  defines  architecture  as:  "in  avionics,  a  representation  of  the  hardware  and 
software  components  of  a  system  and  their  interrelationships,  considered  from  the  viewpoint  of  tbe  whole  system". 
As  far  as  I  am  concerned,  I  would  make  a  distinction  as  part  of  this  definition,  between  the  functional  architecture 
and  the  physical  one.  To  me,  this  would  seem  particularly  important  once  we  try,  as  the  PAVE  PILLAR  concepts 
do,  to  standardize  an  advanced  avionics  architecture,  that  is  ,  to  make  it  common  to  several  aircrafts,  each  with 
different  missions. 

Because  of  the  diversity  of  missions,  the  system  designers  must  be  capable  to  implement  the  operational 
functions  of  an  air  vehicle  (and  only  these  ooes,  for  cost  reasons ),  in  such  a  way  as  to  best  meet  user  requirements. 
From  this  functional  point  of  view,  every  system  should  be  specific,  regardless  of  tbe  level  of  standardization 
demanded  for  Its  components. 

The  functions!  architecture  may  be  defined  as  the  breakdown  of  the  functions  into  functional  modules,  the 
organisation  of  these  modules  and  of  their  interrelationships.  The  purpose  is  to  get  modules  for  parts  of  the 
software  which  can  be  realized  by  one  single  man  and  tested  sepanuely.  To  give  you  an  idea,  modules  could 
contain  up  to  300  instructions  maximum.  The  functional  coherence  is  then  ensured  by  means  of  a  structured  top- 
down  breakdown  approach,  like  die  (DEF  0  method  for  example. 

Physical  architecture  is  related  to  the  harware,  and  may  be  defined  as  the  organization  and  composition  of 
the  hardware  and  the  interrelationships  between  its  components  required  in  order  to  support  the  functions. 

Of  course,  in  order  for  the  hardware  to  be  able  to  support  all  the  functions,  there  must  be  compatibility 
between  physical  and  functional  architectures:  they  are  therefore  closely  related,  and  should  be  designed  together  in 
order  to  produce  a  coherent  s^'stem  which  meets  requirements. 

This  is  of  great  importance  when  we  are  attempting  to  standardize  components  and  rales  for  the  physical 
architecture.  We  shall  see  how  the  question  has  been  resolved  hi  die  case  of  PAVE  PILLAR. 


I  shouk  like  to  add  a  rider  on  that  one,  if  you  will  allow  me.  For  a  long  time  it  has  been  assumed  that 
technology  could  meet  the  increasing  performance  requirements  made  necessary  by  the  developping  threat.  This  has 
undoubtdy  been  the  case,  and  I  trust,  still  is.  There  is  however  a  limit,  which  is  imposed  by  cost.  It  appears  today 
that  even  the  most  powerful  nations  cannot  afford  all  the  high  performance  systems  which  could  give  us  a  decisive 
advantage  over  the  adversary. 

As  we  shall  see,  optimum  architectures  result  in  considerable  cost  savings.  This  is  the  case  for  aircraft 
development  and  acquisition,  where  standardization  approaches  can  prove  highly  beneficial.  It  also  applies  to  life 
cycle  cost,  which  is  an  attractive  prospect,  as  rising  maintenance  costs  eat  into  (he  funding  available  for  new 
developments.  What  is  more,  technology  and  performance  being  equal,  architecture  optimization  produces 
substantial  gains  in  terms  of  availability,  survivability,  maintainability,  whose  effects  come  as  an  aded  bonus  to  die 
reductions  in  maintenance  cost  achieved  by  the  technology  (higher  MTBF)  and  the  architecture  studies  (reduction  in 
the  amount  of  maintenance  levels  and  quantity  of  spore  parts  in  stock,  for  instance). 

As  you  can  see,  these  questions  are  fundamental  to  our  ability  to  produce  efficient  systems. 


A  SYSTEM  APPROACH 

We  have  just  noticed  that  system  design  and  architecture  problems  are  vital.  They  are  also  difficult  to 
master.  Just  think  of  the  number  of  500  lines  modules  that  may  be  contained  in  a  software  program  with  several 
million  instructions!  The  work  involved  in  designing  modem  fighter  avionics  far  exceeds  human  capabilities.  We 
must  therefore  use  stringent  methods,  backed  up  by  efficient  computer  techniques. 

The  French  aeronautics  industry  has  undertaken  in  the  last  years  a  considerable  effort,  with  support  by  the 
Ministry  of  Defence,  in  order  to  introduce  such  facilities  for  the  whole  system  design  cycle. 

This  step  appears  to  me  as  exemplary,  and  I  should  like  to  describe  its  main  principles.  It  is  called  the  IT1 
( Integration  du  Traitement  de  Flnformation)  program  (Data  processing  integration)  which  is  concerned.  It  is  headed 
by  the  Direction  des  Constructions  Aeronautiqu es  (DC Ac),  with  the  assistance  of  eight  companies:  two  aircrafts 
manufacturers,  AEROSPATIALE  and  AMD-BA,  and  six  equipement  manufacturers,  CROUZET,  SAGEM, 
SFENA,  SFIM  and  THOMSON-CSF. 

ITI  offers  a  solution  which  meets  a  number  of  needs  for  the  development  of  future  avionics  systems. 

The  problems  are  the  following. 

-The  growing  importance  of  software,  which  is  also  becoming  increasingly  complex,  as  a  result  of  systems 
integration,  and  because  of  the  fact  that  it  has  to  handle  most  of  the  modifications  made  during  development.  This 
product  must  be  of  maximum  quality,  which  means  channeling  the  creativity  of  those  responsible  for  its  design,  by 
means  of  rigorous  methods  .  The  apparent  ease  whith  which  modifications  can  be  made  is,  in  fact,  a  major  risk  for 
quality.  On  the  other  hand,  and  everyone  finds  this  worrying,  software  is  not  experiencing  the  same  productivity 
growth  as  the  other  activities,  at  the  very  time  when  its  volume  is  increasing  exponentially. 

-The  coexistence  of  various  versions  of  the  same  system,  wether  for  successive  versions  of  the  same 
aircraft  incorporating  new  capabilities,  or  those  intended  for  difTerents  clients. 

-The  growing  proportion  of  on  board  equipment  (for  instance,  60  equipment  items  of  35  different  types, 
and  14  types  of  option  for  die  AIRBUS  A  320) . 

-The  systems  complexity,  due  to  the  performances  specifications,  requiring  leading  edge  technology 
solutions,  and  the  high  number  of  modifications,  lead  to  higher  cost  and  longer  delivery  times. 

Three  major  needs  emerge  from  these  considerations. 

-We  must  have  complete  technical  mastery  of  development.  The  process  must  therefore  be  automated. 

-We  must  control  costs  and  implementation  times,  which  means  improving  our  forecasts,  providing 
efficient  project  management,  and  reducing  or  better  eliminating  risks. 

-We  must  improve  software  quality  and  productivity.  This  means  enforcing  strict  design  rules.  This 
requires  too  powerful  software  specification,  production  and  debugging  aids. 

Moreover,  these  four  points  lead  naturally  to  closer  cooperation  between  the  various  companies  working  on 
a  given  project:  the  amounts  of  data  exchanged  are  enormous.  For  example,  for  one  version  of  the  MIRAGE  2000, 
the  exchanged  documents  (apart  from  user's  documentation  as  such)  represent  a  stack  of  paper  more  than  eight 
meters  high.  Now,  if  tire  tools  used  by  the  different  parties  involved  are  not  harmonized,  this  information  has  to  be 
sorted  more  or  less  manually  at  each  stage  before  being  processed,  which  is  a  considerable  waste  of  time. 

In  order  to  overcome  these  problems,  FT1  has  laid  down  the  following  aims: 

-to  facilitate  communications  between  the  companies  working  on  the  same  project.  This  is  made  possible 
inter  alia  by  the  adoption  of  a  common  work  methodology,  by  automatic  document  processing  and  by  electronic 
mailing  for  transfer  of  documents  in  a  form  directly  usable  by  the  adressee; 

-to  provide  a  system  design  aid,  using  computers  for  design,  specification,  definition; 

•to  provide  a  software  development  aid,  using  computers  for  design,  definition,  encoding  and  testing.  One 
of  the  testing  aids  used,  IDAS,  will  be  discussed  by  MrMUENIER; 
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-to  assist  with  integration  and  validation  of  software  and  systems. 

Interoperability  problems  also  need  to  be  taken  into  account.  Since  the  design  aids  are  to  be  used  by  various 
partners,  they  must  be  compatible  with  any  computer  configuration,  provided  it  meets  certain  standards. 

Finally,  security  objectives  had  to  be  defined:  protection  of  software  against  the  supply  of  erroneous  data 
and  incorrect  handling,  automatic  error  detection  with  tell-back,  etc. 

To  attain  these  various  ends,  an  integrated  workshop  known  as  SDA  (Avionics  Development  System)  was 

setup. 


It  is  an  integrated  workshop  in  the  sense  that  the  aids  that  it  comprise  can  communicate  with  each  other,  and 
exchange  the  results  of  the  tasks  in  which  they  are  involved.  The  structure  of  the  SDA  is  based  on  the  industrial 
organisation  of  a  project,  and  is  on  three  levels.  The  first  is  that  of  communications  between  the  different  companies 
participating  to  a  program.  The  second  is  that  of  the  manufacturer,  who  has  his  own  computing  facilities:  it  is  the 
Manufacturer  Development  System  (SDl-Systeme  de  Developpement  Industriel).  The  third  is  that  of  the  individual 
user  in  his  specific  work  situation  inside  his  company:  it  is  the  Personal  Development  System  (SDP-Systeme  de 
Developpement  Personnel). 

Communications  between  the  SDFs  belonging  to  an  SDI  on  the  one  hand,  and  between  the  SDI’s  within  an 
SDA  in  the  other,  are  provided  by  an  access  structure. 

This  access  structure  combines  the  mecanisms  and  aids  which  are  common  to  all  SDI’s. 

Examples  of  common  aids  are:  the  operating  system,  the  composer,  the  administrator,  the  configuration 
management,  the  object  management  system,  etc. 

On  this  basis,  each  SDP,  depending  on  the  need,  integrates  general  tools  (documentation,  project 
management,  quality,  etc...)  and  specific  tools,  for  the  design  and  elaboration  of  the  functional  architecture 
(identification  of  functions  and  interfaces),  definition  of  the  avionics  system,  specification  of  its  components, 
software  definition  and  design,  software  production  activities  (encoding,  production  of  executables,  individual 
testing,  using  high  order  languages  such  as  ADA  and  LTR  3),  and  integration  and  validation,  using  a  dynamic  test 
aid. 


Clearly,  the  subject  matter  of  this  Lecture  Series  is  vast.  The  concept  of  system  configuration  covers  a 
whole  series  of  activities,  all  of  which  have  their  part  to  play  in  the  production  of  high  performance  aircrafts.  One 
cannot  hope  to  treat  such  a  subject  exhaustively.  I  merely  hope  that  by  the  end  of  the  final  lecture,  you  will  be  aware 
of  the  importance  of  these  problems  though  your  attendance  is  already  proof  of  that,  and  that  you  will  have  a  little 
clearer  perception  of  the  challenges  of  the  near  future. 
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RESUME 

L’avionique  des  a^ronefs  de  combat  modemes  est  de  plus  en  plus  complexe  et  remplit  des 
fonctions  tou jours  plus  nombreuscs.  Pour  cette  raison,  les  probfemes  U6s  aux  configurations  sont  de 
plus  en  plus  imporuuns, 

0  faut  dans  un  premier  temps  d6finir  ce  qoe  Ton  attend  par  configuration  des  syst&nes. 

Ce  faisant,  il  apparalt  claim ment  que  du  fait  de  1’ integration  des  fonctions,  il  est  impossible 
d'isoler  les  systkmes  de  guidage  et  de  pilotage  dfcs  lore  qu ’on  s’int6resse  k  leur  architecture. 

L’ architecture  concemc  aussi  bien  les  Equipements  que  les  syst&mcs  ou  les  fonctions  (done, 
aujourd’hui,  les  logiciels)  .  C'est  pourquoi  des  thdmes  divers  sennit  abordSs  au  cours  des  diff&ents 
exposes :  m^thodes  et  out  Us  de  conception,  calculateurs,  bus  de  donn£es,  outils  logiciel. 

Q  est  peut-£tre  bon  de  diff6rencier  sur  un  a6ronef  l  architecture  fonctionnelle  et 
1' architecture  physique.  Compte  tenu  de  leur  importance  et  de  leur  incidence  sur  les  performances,  la 
fiability,  la  survivability,  fa  maintenabiiity,  les  co&ts,  ct  du  fait  de  la  complexity  des  probtfemes  qui  leur 
sont  l»6s,  leur  Elaboration  n^cessite  des  outils  adapts. 

La  Direction  des  Constroctions  A6ronautiques  et  hurt  soci&ys  fran^aises  ont  fait  un  effort 
paiticulier  pour  rendie  disponible  pour  1’industrie  alronautique  un  atelier  intyp6  pour  la  conception 
des  sysrtmes  avioniques.  D  est  britvement  dycrit. 


INTRODUCTION 

Les  a^ronefs  de  combat  ont  k  faire  face  k  une  menace  qui  ne  cesse  de  crofrre,  cn  quantity 
et  en  quality,  que  ce  soil  au  sol  ou  dans  les  airs,  bient&t  mSme  probablement  dans  t’espace.  Pour 
s’adapter  k  cette  menace,  on  leur  demande  de  remplir  des  fonctions  de  plus  en  plus  nombreuscs,  dans 
des  conditions  plus  difficiles  et  avee  des  performances  tou  jours  amyiior6es. 

Celt  ytant,  le  cofit  des  a6ronefs  ne  cesse  d’augmenter,  aussi  bien  k  1  'acquisition  qu’en 
utilisation  opyratiormefle.  Si  bien  que  pour  rentabiliser  le  cofit  de  dyveloppement  des  avions 
nouveaux,  et  parce  qu’il  est  devenu  difficile  de  supporter  la  charge  financifcre  de  plusieurs 
programmes  parallkles,  une  tendance  k  concevoir  des  a6wnefs  multi-rdles  s’ est  affiim6e  ces  demiers 
temps. 


La  consequence,  c’est  encore  1  ’augmentation  du  noenbre  a  de  la  complexity  des  fonctions. 

Tout  ccla  est  pamculikreniem  vrai  pour  l’avionique  et  les  systfemes  d’armes,  qui 
rempiisaent  dSsormais  l’essenticJ  des  fonctions  dyvadues  k  l’afironef. 

C’est  amsi  que  pour  une  masse  qui  reprtacn tt  de  fagon  constante  environ  le  dbufime  de  la 
masse  k  vide  de  1’avion,  le  cofit  d’acquisition  de  l’avionique  (an  sens  large:  tout  ce  qui  est  yiectronique 
dans  I’aytonef)  ne  cesse  d’augmenter  en  proportion  du  cofit  global,  jusqu’k  environ  40%  pour  les 
avions  de  combat  de  la  proebaine  gynyration,  tandis  que  aon  cofit  de  maintenance  petit  repr6senter 
jusqu’k  80%  du  cofit  de  maintenance  global. 


LA  NOTION  DE  CONFIGURATION 


Voili  lc  cadre.  Dans  ce  contexte,  quel  est  le  rftlc  de  la  configuration  informatique  des 
systfcmes  de  pilotage  et  de  guidage? 

Avan!  tout,  il  est  ikcessaire  de  s ’entendre  sur  ce  que  recouvre  cette  expression. 

La  prise  en  compte  des  contraimes  et  des  besoms  rappel6s  ci-dessus  conduisent  k  une 
imbrication  des  diffirentes  fonctions  rfcalis6es  par  les  systfcmes  de  navigation  et  d’aimement 
modemes. 


Le  guidage  d’un  a6ronef,  par  exemple,  intervient  dans  toutes  les  phases  d’une  mission, 
quelle  qu  'die  soil,  et  doit  traiter  des  informations  qui  provieament  aussi  bien  de  capteurs  autonomes 
(centrales  de  navigation,  ftchiers  de  terrain,...)  que  de  capteurs  de  radio-navigation  (GPS,...),  du  radar 
(profils  de  terrain,  position  des  ciWes,...),  des  contre -mesures  (pour  I’^vitement  des  menaces),  du 
gyst&me  (plan  de  mission,  informations  tactiques,...),  etc. 

Cette  imbrication  des  fonctions,  rkcessaire  pour  maintenir  l’avionique  h  on  volume  et  un 
cout  raisonnables,  et  permise  par  les  technologies  de  la  mkro-^lectnmique,  conduit  k  la  disparition  de 
la  notion  de  sous-systime. 

L’avionique  sc  r6partit  en  fait  entre  des  capteurs,  un  coeur  informatique,  et  des  terminaux 
(visualisations,  commanded,  ou  actionneurs,  essentiellement).  Cda  ne  sigmfic  pas  qu’il  y  ait 
fketssairement  centralisation:  le  coeur  informatique  peut  etre  cotkju  scion  une  architecture  rgpartie, 
certains  prccesseura  pouvant  rester  physiquement  "proches”  des  capteurs  ou  des  terminaux.  Mais 
1  ’ensemble  du  coeur  participe  sou  vent  k  1  ’exploitation  des  informations  provenant  des  capteurs  et  k 
l’61aboration  de  celles  envoy  6es  aux  terminaux. 

La  configuration  informatique  des  systfemes  de  pilotage  et  de  guidage  est  done 
difficilement  dissociable  de  celle  du  coeur  de  I’avionique,  et  ce  sera  de  plus  en  plus  le  cas  dans  le 
futur,  comme  nous  k  verrons  au  cours  de  qudques  exposes. 

Un  systbme  informatique,  e’est  essentiellement,  en  stefnatisant,  des  caiculateurs  ou  des 
processeurs  organises  de  telle  sortc  qu’ils  puissent  supporter  des  fonctions  qui  sont  r6alis6es  par  du 
logic  iel. 


La  configuration  d’un  tel  ensemble  conceme  done  la  conception  et  la  definition  des 
caiculateurs,  1 ’organisation  de  l'ensemble  ou  plus  pr6cis6ment  1’ architecture  du  syst&me,  et  (a  fa^on 
dont  est  con^u  le  iogiciel,  scion  quelle  m&hodologie  et  avec  quels  outils. 


GENERALITES  SUR  LES  CONFERENCES 


On  le  voit.  le  sujet  est  vaste.  Cependant,  j’ai  pens*  qu’il  fallait  essayer  d’aborder  chaque 
theme,  non  pas  bien  stir  pour  les  presenter  de  fetfon  exhaustive ,  mais  en  choisissant  quelques  sujets 
import  ants  oil  les  exposes  montreront  dans  quelles  directions  evolucnt  les  choses  et  quelles  sont  les 
cits  du  futur,  parce  qu’il  me  par  ait  important  de  prendre  conscience  que  toutes  ces  choses  sont  Ii6es, 
sont  les  parties  tndissociables  d’un  tout. 

Ainsi  le  premier  expose,  de  M.  H.  /.  KAUL,  a  borders  les  probldmes  de  conception  des 
systfemes  de  commarvde  de  vol  et  d6crira  des  outils  Iks  k  une  nkthodc. 

Nous  nous  tnt£resserons  au  cours  des  exposes  de  MM.  M.  T.  MICHAEL  et  M.  MUENIER 
aux  procesaeurs  de  traitement  de  donn^es  et  de  signal,  en  particulier  au  CSP,  au  standard  1750  A  et  k 
un  nouveau  processeur  de  haut  niveau,  le  CMF.  Peut-^trc  nous  permettront-ils  d’aborder  des 
questions  desormais  traditionnelles:  faut-il  standardiser  des  caiculateurs,  le  32  bits  va-t-il  supplanter  le 
16  bits,  quel  jeu  d’instmetions.  RISC  ou  non? 

Les  bus  de  donikes,  616ment  essentiel  de  liaison  entre  les  composantes  des  systfemes 
actuels  et  auxquels  des  performances  en  augmentation  notable  sont  demanckes  pour  les  systdmes 
future,  feront  l’objet  de  I'exposS  de  M.  R.  UHLHORN,  qui  abordera  en  particulier  les  bus  opciques  k 
grand  (kbit. 

Le  Iogiciel  bien  stir  ne  peut  etre  absent  ici.  Constituent  essentiel  du  systfcme,  auquel  il 
doime  vie,  son  volume  croft  de  fa^on  exponentieQe,  et  dans  le  mfcne  temps  les  problfcmes  qui  Iui  sont 
attaches.  Sur  des  a6ronefs  existants,  on  peut  conskkrer  que  le  Iogiciel  du  calculator  central  cotite  I 
1’ acquisition  la  moitk  des  caiculateurs  eux-mSmes.  Mais  en  utilisation,  la  proportion  peut  aller  jusqu’k 
80%  des  cotits  de  maintenance. 

Pour  les  afeonefo  future,  qui  inkgreront  plusteure  millions  de  lignes  de  code,  la  quality  et 
la  productivity  en  matifcre  de  Iogiciel  sont  des  points  de  passage  obliges.  M.  MUENIER  nous  parlera 
d’un  outil  de  test  de  Iogiciel,  qui  sera  inkgr €  dans  un  atelier  dont  j’fitrai  1  ’occasion  de  vous  dire 
quelques  mots  par  la  suite. 
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Nous  nous  intferesserons  enfm  aux  pro  blames  d’architecturc  avionique  lore  des  exposes  de 
MM.  J.  C.  OSTGAARD  et  D.  R.  MORGAN  sur  PAVE -PILLAR.  Ccs  presentations  montreront 
1' importance  du  sujet,  tant  par  ses  implications  sur  la  conception  des  systfemes  avioniques  que  par  ses 
consequences  sur  les  performances  et  ies  cofits. 


LE  ROLE  DE  L’ ARCHITECTURE 

Le  STANAG  3908  (Edition  1)  d6finit  rarchitecture  commc  fetant  ”en  avionique,  une 
representation  des  composants  mat6riels  ct  logiciels  d’un  systfeme  et  de  leur  relations,  considferfes  du 
point  de  vue  du  systfeme  global”.  Pour  ma  part,  je  propo  serais  de  distinguer  dans  le  cadre  de  cette 
definition  entre  rarchitecture  fonctionnelle  et  1’ architecture  matferielle.  Cela  me  par  ait 
particuliferement  important  dfes  lore  que  l’on  r  ’:erche,  comme  le  proposent  les  concepts  de  PAVE- 
PILLAR,  de  standardiser  une  architecture  avionique  avanefee,  e’est-fe-dire  de  la  rendre  commune  k 
plusieurs  aferonefs  dont  les  missions  sont  diff6rentes. 

La  diversity  des  missions  impose  en  effet  que  le  concepteur  du  systfeme  puisse  implanter 
les  fonctions  de  1  ’avion  (et  settlement  celles-la,  pour  des  raisons  de  cotit)  pour  rfepondre  au  mieux  aux 
be  so  ins  exprimfes  par  l’utilisateur.  De  ce  point  de  vue  fonctionnel,  chaque  systfeme  doit  pouvoir  etre 
sp^cifique,  quelque  soit  le  niveau  de  standardisation  dfesirfe  pour  ses  composants. 

L’ architecture  fonctionnelle  pourrait  etre  dfefinie  comme  fetant  le  dfecoupage  des  fonctions 
en  modules  fonctionnels,  I’organisation  des  modules  foncttonnels  et  de  leurs  relations.  Aujourd’hui, 
cela  conceme  essentiellement  le  logiciel  d’ application,  Le  but  est  d’obtenir  des  modules 
correspondant  k  des  parties  de  logiciel  rfealisables  par  un  seul  individu,  et  testables  isolfement,  pour 
fixer  les  idfees,  comprenant  un  maximum  de  500  lignes  de  code.  La  coherence  fonctionnelle  est  alore 
assurfee  par  une  decomposition  scion  des  approches  top-down  structur6es,  par  exemple  selon  des 
mfethodcs  du  type  IDEF-0 

L’ architecture  matferielle  conceme  le  hard,  et  peut  etre  dfefinie  comme  l'organisation  et  la 
composition  du  materiel  et  des  relations  entre  ses  elements  en  vue  de  pouvoir  supporter  les  fonctions. 

Bien  entendu,  pour  que  les  ma  tends  soient  capables  de  supporter  routes  les  fonctions,  il 
faut  assurer  la  compatible  des  architectures  fonctionnelles  et  materielles:  elles  sont  done  trfes  li6es 
l*une  k  1* autre  et  doivent  etre  definies  ensemble  dans  le  but  de  realiser  un  systfeme  coherent  repondant 
aux  besoins. 

C’est  particuliferement  important  quand  on  cherche  k  standardiser  des  elements  et  des 
regies  pour  rarchitecture  materielle,  et  nous  verrons  comment  cette  question  a  fetfe  r6solue  dans  le 
cadre  de  PAVE-PILLAR. 

Encore  une  reflexion,  si  vous  le  permettez,  sur  ce  point.  On  a  longtemps  consid6re  que  la 
technologic  permettait  de  rfepondre  aux  besoins  croissants  en  performance  dfls  k  revolution  de  la 
menace.  Cela  est  sfircment  vrai  et,  jc  l’espfere,  se  trouve  verifie  jusqu’fc  present.  Mais  il  y  a  une  limite, 
qui  est  constituee  par  les  cofits.  D  apparait  aujourd’hui  que  les  plus  grandes  nations  ne  peuvent  payer 
tous  les  systfemes  trfes  performants,  qui  pourraient  k  coup  sfir  nous  donner  un  avantage  certain  sur 
l’adversaire. 

La  definition  d ’architectures  optimales  permet,  comme  nous  le  venons,  d’abaisscr 
notablement  le  cofit  des  systfemes.  C’est  le  cas  au  niveau  du  developpcment  ct  de  l’acquisition  des 
aferonefs,  et  Ife,  les  approches  de  standardisation  peuvent  fetre  trfes  ben6fiques.  C’est  aussi  le  cas  pour 
le  cofit  de  cycle  de  vie,  ce  qui  est  particuliferement  int6rcssant,  puisque  1’ augmentation  des  cofits  de 
maintenance  grfeve  sensiblcment  les  capacitfes  de  finance ment  des  dfeveloppements  nouveaux.  Or 
1’ optimisation  des  architectures  apporte,  k  technologic  et  performances  fegales,  des  gains  substantiels 
en  matifere  de  disponibilitfe,  survivability,  maintenabilitfe,  dont  les  effets  s’ajoutent  aux  diminutions  des 
cofits  de  maintenance  obtenues  par  la  technologic  (augmentation  du  MTBF,...)  et  les  Etudes 
d’ architecture  (diminution  du  nombre  des  niveaux  de  maintenance,  du  volume  des  stocks  de 
rechanges,  par  exemple) . 

On  le  voit,  ces  probifemes  constituent  une  clfe  fondamentale  pour  notre  capacity  k  produire 
des  sysffemes  performants. 


UNE  APPROCHE  SYSTEMIQUE 

Nous  venons  de  const  tier  que  les  problfemes  de  conception  des  systfemes,  d*  architecture, 
sont  primordiaux.  Qs  sont  aussi  difficile*  k  maftriser.  Songez  au  nomine  de  modules  de  500  lignes  que 
peut  compter  un  logiciel  de  plusieurs  millions  d’instructkms.  Le  travail  a  accomplir  pour  concevoir 
1’ avionique  des  aferonefs  modemes  dfepasse  les  capacitfes  humaines.  D  est  done  nfecessaire  d ’util we r  des 
mfethodes  rigoureuses,  sous-rendues  par  des  outils  informatiques  performants. 

L’industrie  aferonautiqoe  fran^aise  a  engagfe  ces  demiferes  armies  un  effort  important  pour 
se  doter  d’ outils  couvrant  tout  le  cycle  de  conception  d’un  systfeme,  avec  le  soutien  du  Ministfere  de  la 
Dfefense. 
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Cette  demarche  me  parait  exempUiie  et,  si  vous  k  permettez,  j’aimerais  vous  en  exposer 
ka  priocipea.  II  s’agit  du  programme  ITI  (Integration  du  Trmilemeat  de  I’lnfoanatioo),  merk  par  la 
Direction  des  Constructions  Aeronautiqnra  (DCA6)  auprfes  de  buit  industriels:  deux  avionneurs 
AEROSPATIALE  et  AMD-BA,  et  six  6quipementiere,  CROUZET,  SAGEM,  SEEN  A,  SFIM  et 
THOMSON-CSF 

ITI  propose  one  solution  poor  satisfaire  un  certain  noenbre  de  besoms  pour  le 
ddveloppement  des  systkmes  avioniquea  future. 

Lea  probkmes  sont  lea  survams. 

-L' importance  croisssme  des  logiciels,  par  aiUeure  de  plus  en  plus  complexes  de  par 
{’integration  des  fonctkns  et  parce  que  Ton  re porte  sur  lui  lea  modifications  rkcessaires  au  cours  du 
<kvel  opponent  D  faut  assurer  k  ce  produit  une  quality  maximum,  et  done  canaliser  par  des  nkthodes 
rigoureuses  la  creativity  des  pereonnes  rcspoosabks  de  sa  realisation.  La  facility  apparente  de  fiure 
des  modifications  rat  en  effet  un  risque  majeur  de  non  quality.  D’ autre  part,  et  tout  k  moode  s’en 
inqukte,  on  n ’observe  pas  la  mime  croissance  de  productivity  en  mmtkre  de  logiciel  que  pour  les 
autres  activity*,  alors  que  les  volumes  augmmlent  de  fapm  exponentidle. 

-La  coexistence  de  nombrcuses  versions  de  systfenes,  que  ce  soit  les  versions  success) ves, 
incorporant  des  nouvclles  capacity*,  d’un  mbne  kronef  ou  cedes  destirties  k  des  client  diff£rcnts. 

-La  pan  grandissante  des  6quipemcaU  embarqiks  (par  cxempk  pour  l’A  320,  60 
yquipements  de  35  types  different*,  et  14  types  d’optionnels) . 

-La  complexity  des  systbmes,  dfie  aux  performances  demand6es,  qui  conduisent  k  mettre  en 
oeuvre  des  solutions  1  la  pointe  de  la  techoologie,  et  le  nombre  des  modifications  k  prendre  en 
compte,  font  augmenter  les  cotits  et  les  deiais. 

D  en  d6coule  trois  grands  besoms. 

-D  ‘‘aut  garantir  le  mahrise  technique  du  ckvdoppement.  D  faut  done  automatiser  le 

processus. 


-II  faut  maitriser  les  cotits  et  les  deiais,  et  pour  cela,  anktiorer  les  provisions,  assurer  un 
suivi  de  projet  efficace,  et  r6duiie,  et  essayer  d’diminer,  les  al6as. 

-D  faut  anktiorer  la  quality  et  la  productivity  en  matkre  de  logiciel. Cela  implique 
d’ impose r  des  regies  strides  de  conception.  Cela  demande  aussi  des  outils  puissants  d’aide  4  la 
specification,  k  la  realisation  et  k  la  validation  des  logiciels. 

De  plus,  ces  quatre  points  induisent  naturellement  un  accroissemem  des  relations  entre  les 
divers  coop6rants  d’un  programme:  les  volumes  de  dotukes  6chang6es  deviennent  6normes  Par 
exemple,  pour  une  version  du  MIRAGE  2000,  l’cnsemble  des  documents  6chang6s  (hors 
documentation)  reprfaeme  une  pik  de  papier  de  plus  de  8  nktres  de  hauteur.  Or,  s’  il  n’y  a  pas 
harmonisation  des  outils  des  intervenants,  ces  informations  doivent  titre  tessaisies  plus  ou  moms 
manuellement  k  chaque  6tape  du  processus,  avant  leur  exploitation,  ce  qui  repksente  une  perte  de 
temps  inutile. 

Poor  parvenir  1  renkdiex  aux  probfcmes,  m  s’est  fix6  les  objectifs  su  wants: 

-faciliter  la  communication  entre  les  industriels  intervenant  dans  un  projet.  Cela  est  rendu 
possible  entre  autres  par  l'adoption  d’une  nkthodologk  de  travail  commune,  par  la  realisation  de 
fa^on  automarique  de  documents  informatia6a,  et  par  une  messagerie  nformatique  permettant 
I'Achange  de  ces  documents  sous  une  forme  directement  exploitable  par  le  destinataire; 

-apporter  une  aide  k  la  conception  des  sys times,  grice  k  des  outils  informatiques  pour  la 
conception,  la  specification  et  la  definition; 

-apporter  une  aide  au  d6vcloppemcm  des  logiciels  nice  k  des  outils  pour  la  definition,  la 
conception,  le  codage  et  le  test.  Un  outil  de  test  letenu  est  IDAS,  qui  fern  l’objet  du  deuxkme  expose 
deM.  MUENIER; 


-aider  k  1‘ integration  et  k  la  validation  des  logiciels  et  des  systtmes. 

De  plus  sont  pria  en  compte  des  objectifs  de  portability.  Les  outils,  dev  ant  Ctre  utilises  par 
plusieure  intervenants,  doivent  pouvoir  etre  implants  sur  chaque  configuration  infbrmatique  ,  k 
condition  qu’elle  satisfasse  certains  standards. 

Enfin  ont  &y  definis  des  objectifs  de  securhe:  protection  des  logiciels  cootre  la  foumituxe 
d‘ informations  errooies  et  les  mauvaiaes  manipulations,  detection  automatiqoe  d’eneure  avec  compte 
rendu,  etc. 


Pour  atcindre  ces  divers  objectifs,  un  atelier  integre,  appcie  SDA  (Systtene  de 
Devdoppcment  d’Avionique),  a  M  defini. 

C’est  tan  atelk  irtfegrf  en  ce  sera  que  toos  ks  outils  qu’fl  comporte  peuvent  communiquer 
entre  an,  et  s’echanger  les  resultats  des  tiches  tnxqods  0a  concoorent. 
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L’organisation  du  SDA  est  caique®  wax  (’organisation  industncllc  d  un  projet,  et  comprend 
trois  niveaux.  Le  premier  est  celui  des  comnuinication*  cntrc  les  divers  industriels  participant  au 
programme.  Le  deuxiime  niveau  est  cdui  de  1’industnd  qui  dispose  de  moyens  informal  iques 
propres:  e’est  le  Systfeme  de  Dtvdoppement  Industrie!,  SDL  Le  troisifeme  est  celui  de  l’utilisateur 
individuel  dans  son  cortex  te  de  travail  k  l’intdieur  de  son  entrcprise:  e’est  le  Systfeme  de 
D^veloppemertt  Personnel ,  SDP. 

Les  communications  entre  les  SDP  apparttaoart  i  un  SDI  d  une  part,  et  entre  les  SDI  relies 
au  sein  d'un  SDA  d’autre  part,  sort  assumes  par  une  structure  d’accueil. 

Cette  structure  d’accuei)  rassembie  les  m6caniames  et  outils  commons  k  tous  les  SDL 

Les  outils  convnuns  sort  par  exempfe:  le  systtme  d’ exploitation,  le  compositeur, 
1' administrates,  la  gestion  de  la  configuration,  le  systbne  de  gestion  d’objet,  etc. 

Sur  cctte  base,  chaque  SDP  inti gre  en  fonction  de  ses  besoins  des  outils  g6n6raux 
(documentation,  gestion  de  projet,  quality,  etc)  et  des  outils  sp6cifiques,  pour  la  conception  et 
(’elaboration  de  1’ architecture  fonctionnelk  (identification  des  fooctions  et  des  interfaces),  la 
definition  des  systimes,  la  specification  de  leurs  composants,  la  definition  et  la  conception  du  logiciel, 
les  activites  de  sa  realisation  (codage,  production  d’ex6cutable,  tests  unitaires,  avec  des  langages  de 
haut  niveau,  comme  ADA  et  LTR  3),  rirt£gratioo,  et  la  validation  k  I’aide  d’un  outil  de  test 
dynamique. 


CONCLUSION 

H  est  clair  que  le  sujet  de  ce  cycle  de  conferences  est  vaste.  La  notion  de  configuration  des 
systemes  recouvre  toute  une  siric  d ’activites,  qui  concourent  chacune  d’elle  k  la  realisation  d’a6ronefs 
performants.  On  ne  peut  esperer  aborder  chaque  sujet  de  maniere  complete.  respire  seulement  que 
demain,  apres  le  dernier  expose,  vous  aurez  conscience  de  (’importance  de  ces  probiimes  (mais  votre 
presence  ici  prouve  que  e’est  dejk  le  cas),  et  aurez  une  vision  un  peu  plus  nette  des  challenges  du 
proche  avenir. 
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ABSTRACT 

Flight  Control  Systems  (FCS)  for  present  and  future  Fighter  Aircraft  develop¬ 
ments  are  based  on  three  basic  technologies,  CCV-ACT-digital  signal  processing. 
These  technologies  have  opened  a  new  degree  of  freedom  for  optimizing  overall 
weapon  system  performance  by  extending  the  requirements  to  be  implemented  by  the 
FCS.  The  computing  subsystem  of  the  FCS  is  the  key  element  of  the  FCS  by  which 
this  performance  optimization  can  be  achieved.  Digital  FCS  for  fighter  aircraft 
in  service  or  under  development  exhibit  a  basically  common  architecture  (static 
parallel  redundancy,  centralized  heavily  burdened  computing  subsystem)  which  has 
continuously  evolved  since  the  early  days  of  CCV  and  ACT  activities.  The  object¬ 
ives  of  the  paper  are  to  relate  this  classical  architecture  to  the  advancing  re¬ 
quirements  and  the  new  emerging  technologies  and  to  analyse  its  potentials  for 
future  developments.  From  an  airframe  manufacturers  point  of  view  the  paper  will 

o  attempt  a  critical  review  of  the  interrelationship  between  weapon  system 
performance  and  design  considerations  involved  in  the  development  of  the 
computing  subsystem  of  the  FCS  (present  and  future). 

o  address  the  problem  of  restrictions  imposed  upon  the  application  of 

advanced  computer  hardware/software  and  micro-electronic  technologies  by 
FCS  specific  design  considerations  (present). 

o  identify  the  need  to  overcome  state  of  the  art  FCS  architectures  in  order 
to  fully  utilize  the  potential  of  emerging  technologies  for  the  benefit  of 
weapon  system  performance  through  an  advanced  design  of  the  computing 
sub-system  of  the  FCS  (future). 


LIST  OF  ABBREVIATIONS 

ACT  Active  Control  Technology 

A/C  Aircraft 

ADS  Air  Data  System 

ADT  Air  Data  Transducer  Unit 

ASIC  Application  Specific  Integrated  Circuit 

AVS  Avionic  System 

BC  Bus  Controller 

BIT  Built-In-Test 

CCV  Control  Configured  Vehicle 

CBIT  Continuous  Built-In-Test 

C.G.  Centre  of  Gravity 

CIFU  Cockpit  Interface  Unit 

CBIT  Continuous  Built-In-Test 

CISC  Complex  Instruction  Set  Computer 

CMAM  Custom  Monolithic  Analogue  Microcircuit 

CPU  Cenral  Processing  Unit 

DARPA  Defense  Advanced  Research  Projects  Agency 

DDV  Direct  Drive  Valve 

DSP  Digital  Signal  Processing 
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EAP  Experimental  Aircraft  Programme 
EFA  European  Fighter  Aircraft 

EHSV  Electro  Hydraulic  Servo  Valve 
EMP  Electromagnetic  Pulse 

EMI  Electromagnetic  Interference 

FCS  Flight  Control  System 

FCC  Flight  Control  Computer 

FH  Flying  Hours 

HQ  Handling  Quality 

I B I T  Initiated  Built-In  Test 

ICO  Interface  Control  Document 

IMS  Inertial  Measurement  System 

IMU  Inertial  Measurement  Unit 

INR  Initial  Nuclear  Radiation 

I/O  Input/Output 

IPSE  Integrated  Project  Support  Environment 

LRI  Line  Replaceable  Item 

LRM  Line  Replaceable  Module 

LSI  Large  Scale  Integration 

LVDT  Linear  Variable  Differential  Transformer 

MBB  Messerschmitt-Bolkow-Blohm  GmbH 

NEMP  Nuclear  and  Electromagnetic  Pulse 

PFC  Pre-Flight  Check 

RFI  Radio  Frequency  Interference 

RISC  Reduced  Instruction  Set  Computer 

RT  Remote  Terminal 

RVDT  Rotary  Variable  Differential  Transformer 

SDI  Strategic  Defense  Initiative 

VLSI  Very  Large  Scale  Integration 


1.  INTRODUCTION 

Present  and  future  developments  in  the  field  of  combat  aircraft  are  based  on  the 
principles  of  CCV  technology.  The  design  process  of  the  airframe  can  be  carried 
out  without  a  too  restrictive  need  for  compromise  with  stability  and  control  re¬ 
quirements.  The  advantage  for  a  fighter  to  be  gained  from  this  approach  are  fo¬ 
cussing  on  enhanced  manoeuvrability,  high  performance  and  excellent  and  full 
carefree  handling  and  control  of  the  aircraft.  This  leads  to  configurations  with 
a  high  level  of  longitudinal  instability  together  with  a  partial  instability  in 
the  lateral  axis  which  in  consequence  dictates  a  need  for  a  full-time  authority 
fly-by-wire  system. 

Major  developments  like  CCV-F104,  Jaguar  FBW,  F16,  F18  and  EAP  [1,2]  have 
brought  the  technology  for  such  FCS's  to  a  highly  mature  state.  Advances  in  Act¬ 
ive  Control  Technology  (ACT)  and  the  increasing  performance  of  digital  signal 
processing  have  opened  a  new  degree  of  freedom  for  optimizing  overall  weapon 
system  performance  through  the  design  of  the  FCS.  However,  one  has  to  recognize 
that  the  systems  in  service  so  far  have  utilized  only  a  small  segment  of  this 
potential.  Recent  Experimental  programs  like  X-31  and  EAP  are  gradually  extend¬ 
ing  into  this  potential.  The  maturity  mentioned  above  means  that  we  have  learned 
to  cope  with  associated  safety  issues  within  the  constraints  of  available  imple¬ 
mentation  technologies.  Keeping  this  experience  as  an  essential  basis,  new  de¬ 
velopments  can  extend  their  functional  performance  [3]. 

In  the  area  of  CCV  and  the  associated  FCS  technologies,  MBB  has  an  accumulated 
experience  over  a  wide  range  of  activities  (see  Fig.  1)  starting  from  the  CCV- 
F104  program  through  to  the  beginning  of  the  development  phase  for  the  European 
Fighter  Aircraft  (EFA)  program  and  the  X-31  program. 
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For  a  fighter  aircraft  { A/C )  developed  along  the  line  of  a  CCV  approach,  the  FCS 
performs  a  twofold  function, 

o  It  forms  an  integral  unit  together  with  the  airframe  -  the  weapon  system 
carrier  -  optimized  with  respect  to  manoeuvrability  and  performance 

o  It  is  an  integral  part  of  the  avionic  suite  loaded  into  the  carrier  with 
the  aim  to 

-  assist  the  pilot  in  performing  his  tactical  task  and 

-  provide  semi-  and  fully  automatic  modes  to  enhance  weapon  system 
effectiveness 

The  functions  to  be  performed  by  the  flight  controller  are  summarized  in  Fig.  2. 

The  specification  of  a  full  authority,  full  time  fly-by-wire  control  system 
architecture  i.e,  with  no  facility  for  reversion  to  mechanical  controls  is  a 
technology  integration  task.  State-of-the-art  assessments  and  trends  in  the  un¬ 
derlying  computing,  sensing  and  actuation  areas  have  to  be  performed  to  select 
from  a  number  of  design  alternatives.  Since  this  paper  concentrates  on  FCS  com¬ 
puting  system  conf iguration  aspects  only,  all  sensing  and  actuation  design  con¬ 
siderations  are  addressed  from  the  computing  point  of  view.  The  computing  system 
(see  Fig.  3)  comprises  the  following  functional  elements. 

o  Processing  of  sensor  raw  data 

o  Processing  of  signals  from/to  related  cockpit  elements 

o  Flight  controller  algorithms 

o  Actuator  loop  closures 

o  Signal  transmission  within  the  computational  system  and  between  the  com¬ 
putational  system  and  the  sensors,  FCS  related  cockpit  elements  and 
actuators 

o  Communication  with  general  systems  and  the  avionic  system 
o  FCS  failure  tolerance  and  reconfiguration  capability 

o  Control  and  management  of  all  tasks  within  the  computational  system 

All  functional  elements  outside  this  definition  will  only  be  addressed  with  re¬ 
spect  to  their  impact  on  the  functional  elements  listed  above.  This  rather  broad 
definition  supports  a  line  of  discussion  starting  from  functional  aspects  re¬ 
flecting  the  requirements  down  to  implementation  issues.  The  following  sections 
will  outline  from  an  airframe  manufacturers  point  of  view  the  FCS  design  object¬ 
ives  and  constraints  in  the  light  of  (present  and  future)  computing  system  de¬ 
sign  considerations,  present  restrictions  imposed  upon  the  application  of  ad¬ 
vanced  computer  hardware/software  and  the  potential  of  emerging  technologies 
for  the  benefit  of  weapon  system  performance. 

2.  ANALYSIS  OF  REQUIREMENTS 

2.1  Airframe  Related  Requirements 

The  first  task  a  FCS  has  to  perform  in  a  CCV-A/C  is  to  ensure  stability  and 
thus  providing  a  basis  for  acceptable  control  characteristics.  CCV  technology 
does  not  mean  that  the  aerodynamicist  has  unrestrained  freedom  in  defining  the 
aircraft  configuration.  The  control  system  imposes  restrictions  on  the  allow¬ 
able  Instability  levels. 

In  the  early  stage  of  the  definition  of  the  airframe,  a  simple  model  of  the  en¬ 
visaged  control  system  must  be  defined  on  the  basis  of  past  experience  data 
(see  Fig.  4).  Closed  loop  simulation  work  with  preliminary  aerodynamic  data  re¬ 
presenting  the  airframe  and  the  controller  model  are  used  to  define  acceptable 
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instability  levels.  These  simulations  shall  ensure  that  the  stability  require¬ 
ments  defined  in  MIL-F-9490D  will  be  met  by  the  augmented  airframe  in  the 
following  areas. 

o  in  the  whole  envisaged  flight  envelope 
o  for  all  planned  configurations  (stores) 

o  for  all  c.g.  locations 

Once  the  process  of  defining  the  aerodynamic  configuration  has  converged  to  a 
configuration  freeze,  the  control  system  model  and  its  parameters  become  the 
dominant  requirements  for  the  FCS  design.  During  the  subsequent  development 
process,  the  compliance  of  the  implementation  elements  with  this  model  has  to  be 
monitored  very  closely. 

Since  the  control  system  model  leading  to  this  prime  set  of  requirements  has  to 
be  defined  in  an  early  stage  of  a  project,  the  data  used  must  have  a  level  of 
confidence  which  is  dependent  on  development  risk  accepted  for  the  program.  Ta¬ 
king  a  medium  level  of  development  risk,  this  means  that  the  parameters  repre¬ 
senting  system  components  (sensors,  computers,  actuators,  etc.)  reflect  techno¬ 
logies  which  have  been  proven  in  at  least  a  laboratory  environment  approximately 
5  years  prior  to  first  flight. 

An  important  step  is  to  define  a  subset  of  the  above  control  system  model  which 
represents  the  minimal  configuration  of  the  control  system  required  to  provide 
stability  levels  within  restricted  flight  and  manoeuvre  envelopes  sufficent  to 
recover  the  aircraft  in  case  of  system  failures,  i.e.  Operational  State  111  as 
defined  in  MIL-F-9490D.  This  minimal  configuration  defines  the  safety  critical 
functional  path  of  the  system. 

Another  important  function  of  the  control  system  related  to  the  airframe  is  the 
automatic  control  of  the  aerodynamic  configuration.  A  typical  example  is  given 
in  Fig.  5  to  demonstrate  the  multiple  use  of  the  aerodynamic  control  surfaces. 
Besides  stabilization  and  control  they  are  used  for  trim  and  performance  optim¬ 
ization  and  control  of  aerodynamic  configuration  to  improve  on  lateral  direct¬ 
ional  stability  at  high  incidence  providing  satisfactory  levels  of  spin  depart¬ 
ure  resistance  [2], 

2.2.  Handling  Performance  and  Automatic  Modes 

The  outcome  of  the  airframe  related  requirements  for  the  control  system  forms 
the  basis  for  the  subsequent  work.  The  major  impact  of  this  work  on  the 
controller  requirements  and  consequently  on  the  computing  system  is  through 

o  an  extension  of  the  required  measurement  values  for  pitch  angle  (theta) 
and  bank  angle  (phi)  both  needed  for  g-compensation 

o  the  definition  of  the  scheduling  parameters  required  by  the  control  laws. 

A  schematic  block  diagram  of  the  resulting  control  law  structure  is  given  in 
Fig.  6. 

Carefree  manoeuvring  of  the  aircraft  is  one  of  major  objectives.  This  rather 
vague  expression  summarizes  the  functions  which  have  to  be  incorporated  to  en¬ 
sure  an  automatic  way  that  the  safe  flight  envelope  of  the  aircraft  is  respected 
wherever  possible  and  without  compromising  manoeuvrability.  Though  raising  com¬ 
plicated  issues  when  designing  the  associated  control  law  algorithms,  its  impact 
through  the  functional  requirements  on  the  computing  subsystem  is  relatively 
simple.  All  measured  parameters  being  subject  to  an  automatic  control  are  al¬ 
ready  contained  in  the  aforementioned  requirements  such  as  incidence  and  side¬ 
slip,  vertical  acceleration  nz  and  airspeed.  The  additional  requirement  is  for 
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parameters  needed  to  define  the  actual  limitations  such  as  aircraft  mass,  c.  g 
locations  and  external  stores  configuration.  These  parameters  have  to  be  made 
available  to  the  flight  control  system  through  communication  with  uther  aircraft 
systems . 

The  problems  associated  with  the  topic  of  automatic  modes  are  beyond  those  of 
conventional  basic  Autopilot  Modes.  They  reflect  the  important  step  from  pilot 
interpreted  integration  to  the  next  higher  level  of  automated  integration,  (see 
Fig.  7).  An  example  is  the  integration  of  FCS  and  engine  control. 

The  complete  set  of  functional  elements  constituting  such  automatic  modes  are 
not  attributable  to  the  flight  controller  alone.  It  is  a  task  for  overall 
avionic  system  design  to  resolve  the  total  function  to  subsystem  level  whereby 
the  flight  control  system  is  regarded  as  a  subsystem.  The  impact  on  the  comput¬ 
ing  section  of  today's  FCS  is  through  software  requirements  and  requirements 
for  the  communication  system  to  avionic  subsystems. 

2.3  Fault  Tolerance  Requirements 

The  functions  of  the  flight  controller  and  their  performance  level  are  dependent 
on  the  system  failure  state  (Table  1).  The  definition  of  operational  states  IV 
and  V  was  chosen  to  cover  the  peculiarities  of  flight  control  systems  for  highly 
unstable  airframes.  The  detailed  reasoning  behind  this  is  beyond  the  scope  of 
this  paper  but  it  simply  says  that  you  can  either  fly  the  aircraft  within  the 
performance  of  state  III  or  you  lose  it.  The  relation  between  the  operational 
states  and  the  safety  and  mission  requirements  is  shown  in  Fig.  8 

The  current  design  objective  is  that  aircraft  losses  due  to  hazardous  technical 
failures  in  the  FCS  alone  shall  not  exceed  1  x  10-6/FH.  The  total  aircraft  loss 
rate  attributable  to  both  FCS  failures  alone  and  FCS  failures  in  combination 
with  failures  in  other  aircraft  subsystems  (including  total  loss  of  electrical 
and  hydraulic  supplies  affecting  the  FCS)  shall  not  exceed  2  x  10-6/FH.  This 
requirement  is  harmonized  with  the  overall  aircraft  loss  rate  and  connected  to 
the  contribution  of  other  vital  A/C  systems  such  as  engines,  hydraulic  supplies, 
etc.  It  seems  to  be  a  valid  assumption  that  this  requirement  will  not  go  up  for 
future  fighter  A/C  developments. 

The  electrical  part  of  the  FCS  which  uses  primary  inputs  lie.  pilot  commands 
and  aircraft  rate  and  acceleration  sensors)  and  drives  the  first  stages  of  the 
primary  control  actuators  shall  be  capable  of  continuing  to  operate  after  any 
single  failure  without  significant  loss  of  performance,  furthermore  sequential 
double  failures  shall  be  survived,  albeit  with  some  loss  of  performance. 
Secondary  functions  which  optimize  the  performance  of  the  aircraft  but  may  fail 
passively  can  be  of  a  lower  redundancy  level  provided  the  overall  integrity 
requirement  for  the  system  is  met. 

These  requirements  can  usually  be  satisfied  by  conventional  triplex  or  quadrup- 
lex  systems  whereby  the  lanes  are  determined  by  the  redundant  computing  elements 
of  the  safety  critical  functional  path,  the  choice  depending  on  whether  a  100  % 
"two  fai 1-operate"  requirement  is  imposed. 

The  contribution  of  the  FCS  to  aircraft  mission  failure  rate  (i.e.  to  operate 
the  A/C  as  a  weapon  system)  shall  not  exceed  2  per  1000  missions  excluding  hy¬ 
draulic  and  electrical  supplies.  One  or  a  combination  of  the  following  condi¬ 
tions  are  identified  to  cause  an  aborted  mission: 

o  the  degradation  of  the  redundancy  level  of  the  FCS  is  such  that  a  next 
failure  could  result  in  the  loss  of  the  A/C; 

o  the  HQ  (MIL-F-8785)  are  degraded  down  to  level  3; 
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o  the  degraded  performance  is  not  adequate  for  any  remaining  part  of  the 
mission; 

o  the  Pre-flight  Check  (PFC)  results  in  a  NO-GO  condition 

A  mission  may  be  reduced  if  the  failure  situation  of  the  FCS  results  in  one  or 
a  combination  of  the  following  conditions: 

o  The  HQ  are  degraded  down  to  Level  2; 

o  The  degraded  performance  is  not  adequate  for  all  parts  of  the  mission. 

For  the  assessment  of  mission  reliability  an  approximative  method  is  applied, 
which  combines  mission  rates  and  times  of  a  mission  scenario  in  order  to  obtain 
a  mission  reliability  figure. 

The  defect  rate  of  the  FCS  shall  not  exceed  20  per  1000  FH  and  does  not  include 
hydraulic  and  electric  supplies. 

The  apportionment  of  reliability  figures  to  electronic  equipments  is  based  on 
the  following  considerations: 

o  the  requirements  to  be  fulfilled  for  the  total  system  are  the  starting 
point 

o  the  relative  complexity  of  the  LRIs  defines  apportionment  of  the  total 
figures 

o  the  figures  derived  in  this  manner  are  to  be  compared  with  available 

information  about  failure/defect  rates  of  comparable  equipments  used  in 
other  projects 

o  relationship  of  defect  rate  to  failure  rate 

o  relation  between  flying  hours  and  operating  hours 

o  a  "reserve  factor"  is  to  be  applied  in  order  to  counter  for  possible 

non-fulfillment  of  specified  figures,  i.e.  the  specified  figures  are  made 
more  stringent  than  the  apportioned  figures. 

2.3.1  Redundancy  Management  Requirements 

The  FCS  has  to  possess  redundancy  management  techniques  capable  of  providing 
optimum  failure  survivability  via  detection  and  isolation  of  failed  components 
and  reconfiguring  the  remaining  healthy  components  to  provide  the  maximum  level 
of  aircraft  safety  and  the  highest  probability  of  mission  completion.  A  safe, 
dependable  failure  detection  and  identification  scheme  is  necessary  for  detect¬ 
ing  and  isolating  failures  in  FCCs,  sensors,  data  links,  actuation  systems, 
electrical  power  supplies,  hydraulic  power  supplies  in  such  a  manner  that  it 
does  not  degrade  the  capability  to  detect  and  isolate  subsequent  failures.  If  a 
failure  has  been  detected,  reconf iguration  to  the  next  lower  redundancy  level  of 
the  affected  function  shall  be  performed  and  no  unacceptable  transient  be  caused 
due  to  reconfiguration.  Once  a  degradation  of  redundancy  level  has  taken  place, 
the  system  shall  not  automatically  upgrade  to  the  next  higher  level  if  the 
failure  disappears.  System  degradation  by  nuisance  reconfiguration  due  to  false 
alarms  must  be  considered  when  system  performance  is  being  evaluated. 

The  FCS  shall  be  safely  upgraded  by  issuing  a  pilot  initiated  reset  which  shall 
lead  to  a  reconfiguration  state  in  which  attempts  shall  be  made  to  reset  all 
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faulty  elements  after  appropriate  tests.  Only  a  single  failure  in  a  sensor  set 
can  be  cleared  if  the  sensor  successfully  passed  the  reset  test  and  no  dormant 
failure  or  singularity  shall  arise  as  a  result  of  this  action.  Only  one  off-line 
lane  can  be  upgraded  at  a  time  in  a  similar  procedure.  This  capability  will 
improve  the  mission  completion  rate. 

Voter-  and  failure  detection  and  diagnostic  algorithms  have  to  be  a  function  of 
the  current  sensor  set  configuration  as  defined  by  a  consistent  view  of  all  non- 
faulty  channels  and  must  be  capable  of  meeting  the  failure  transient  require¬ 
ments.  Means  have  to  be  provided  to  cope  with  malicious  faults  in  the  data  re¬ 
plication  step  of  time-varying  data  (input  sensors)  in  such  a  manner,  that  the 
likelihood  of  not  reaching  exact  mutual  agreement  in  all  non-faulty  lanes  at  the 
voter  output  is  compatible  with  the  overall  integrity  objective  of  the  F CS .  Re¬ 
sults  of  the  input  voting  plane  which  consists  of  analogue,  discrete  and  digital 
input  signal  management  form  the  values  which  are  supplied  to  other  tasks  (e.g. 
control  laws  etc.).  The  signal  management  of  control  law  demands  shall  produce 
output  demands  that  do  not  drift  apart  greater  than  a  constant  tolerance  with 
respect  to  one  another  in  all  non-faulty  channels. 

The  FCS  has  to  process  data  from  the  various  voter /monitors  so  as  to  reduce  the 
number  of  different  warnings  to  be  displayed  to  the  pilot  as  far  as  practical. 
Only  failures  which  affect  handling  or  require  pilot  action  will  be  reported  to 
the  pilot  and  circumstantial  data  recorded  by  the  system.  FCS  warnings  are 
divided  into  two  groups: 

o  First  and  second  failure  of  similar  functions 

o  Failures  requiring  some  particular  pilot  actions  or  the  observation  of  a 
restricted  flight  envelope. 

Various  surveys  [4,  5.  6,  7]  of  fault- tolerant  computing  introduce  many  of  the 
concepts  and  definitions  relevant  to  redundant  digital  systems,  but  they  need  to 
be  interpreted  in  the  light  of  the  FCS  application.  Moreover  the  references 
cited  above  do  not  all  agree  on  the  definitions.  A  consistant  set  of  fault  to¬ 
lerance  terminology  should  be  adopted  within  the  industry  as  currently  different 
definitions  are  used  by  the  customer,  airframe  manufacturer  and  equipment  supp¬ 
lier  alike. 

Redundancy  management  strategies  are  presently  almost  exclusively  directed  at 
protection  against  random  hardware  faults  and  fault  avoidance  techniques  have 
been  the  main  method  to  achieve  high  integrity  software.  The  research  community 
has  developed  several  approaches  to  the  implementation  of  software  fault  toler¬ 
ance,  the  proposals  that  have  received  the  most  attention  are  N-version  pro¬ 
gramming  and  recovery  blocks.  These  methods  are  faced  with  several  practical 
difficulties  in  its  implementation  [16,  17]  and  will  not  be  discussed  here. 
Hardware  diversity  ("dissimilar  processors")  and/or  analogue/digital  back-up 
system(s)  with  at  least  level  3  handling  characteristics  as  a  concept  to  cir¬ 
cumvent  the  existence  of  design  (generic)  faults/errors  places  an  additional 
burden  on  the  development  process  vihere  the  gains  can’t  be  quantified  since  it 
is  impossible  to  predict  the  probability  of  occurrence  of  generic  errors  and 
this  approach  can  create  more  difficulties  than  it  removes.  The  inclusion  of  a 
back  up  system  is  often  based  on  emotional  feelings  and/or  because  the  purchaser 
does  not  belief  that  the  integrity  of  the  software  can  be  adequately  demon¬ 
strated  but  can  lead  to  a  relaxation  of  design  discipline. 

State-of-the-art  FCS's  exhibit  the  common  characteristic  of  parallel  redundancy 
in  the  computing  section  as  the  basic  element  of  failure  tolerance.  It  is  a 
traditional  issue  to  discuss  the  required  number  of  redundant  lanes  whereby  the 
discussion  is  limited  to  triplex  versus  quadruplex.  The  discussion  is  often 
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biased  by  the  hidden  implication  that  a  triplex  structural  system  is  more  ad¬ 
vanced  than  a  quadruplex  one. 

To  ensure  the  functioning  of  the  safety  critical  path  as  defined  in  section  2.3 
is  the  prime  objective  and  related  to  this  set  of  elements,  the  second  failure 
requirement  determines  the  level  of  redundancy. 

o  A  coverage  factor  (a  quantitative  description  of  success  in  failure  de¬ 
tection  and  isolation)  of  c  =  1  defines  a  quadruplex  configuration. 

o  A  coverage  factor  of  c  <  1  offers  the  chance  to  trade-off  triplex  versus 
quadruplex. 

This  trade-off  requires  the  careful  considerations  of  various  aspects: 

o  A  triplex-redundant  FCS,  where  emphasis  is  placed  on  self-moni toning, 

still  requires  considerable  development  to  achieve  the  high  coverage  for 
the  two  fail  operational  requirement  and  to  lower  the  extreme  cost  of 
verification  and  validation.  Selfchecking  processor  pairs  claim  100  % 
coverage,  but  double  hardware  complexity.  The  advent  of  VLSI  offers  an 
opportunity  to  reexamine  existing  redundancy  techniques  and  apply  them  to 
develop  FCS's  that  achieve  not  only  the  stringent  flight  safety  require¬ 
ments  but  are  also  more  cost  effective. 

o  The  achievable  benefits  from  reducing  a  quadruplex  architecture  to  a  trip¬ 
lex  one  of  the  same  functional  range.  The  improvements  in  system  weight, 
mission  reliability  and  FCS  defect  rate  have  been  estimated  for  a  system 
as  described  in  section  3  to  lie  in  the  range  of  10  X  to  15  %  of  these  for 
a  quadruplex  system. 

A  triplex  architecture  clearly  increases  the  complexity  and  hence  the  effort  for 
validation  of  the  safety  critical  functional  path.  MBB  decided  to  adopt  the  less 
complex  quadruplex  system  and  to  increase  complexity  and  validation  effort  in 
areas  where  mission  probability  can  be  improved. 

The  FCS  example  under  discussion  is  based  on  a  quadruplex,  minor  frame  synchron¬ 
ized,  architecture  with  comparison  monitoring  (cross  lane  monitoring)  as  the 
principal  method  of  failure  detection  and  isolation.  Self  tests  (in  lane  moni¬ 
toring)  are  not  the  primary  means  of  defence  but  are  used  to  enhance  the  failure 
detection  coverage  in  areas  where  otherwise  defects  might  remain  dormant  in 
flight  and  to  enhance  the  availability  of  secondary  facilities  (sensors  or  actu¬ 
ators)  so  as  to  improve  overall  system  reliability. 

The  method  of  analytic  redundancy  can  be  used  for  either  in-lane  monitoring  or 
to  generate  additional  inputs  to  crosslane  monitors  By  this  is  meant  the  use 
of  relationship  among  dissimilar  sensors  to  achieve  fault  detection  and  isola¬ 
tion.  The  use  of  analytically  generated  signals  has  seen  much  research  in  recent 
years  aimed  at  reducing  the  cost  of  redundant  hardware  and  improving  aircraft 
survivability  by  allowing  more  dispersion  of  components.  Analytical  redundancy 
will  only  be  accepted  if  the  analytical  model  can  be  determined  with  sufficient 
accuracy  (e.g.  adequate  knowledge  of  the  sensor  characteristics  during  a  failure 
is  available  and  correctly  modelled)  prior  to  first  flight,  and  therefore  no 
additional  flight  test  results  shall  be  required  to  determine  the  model  or  any 
parameter  associated  with  analytical  redundancy. 

3.  FLIGHT  CONTROL  COMPUTING  DESIGN  CONSIDERATIONS 

The  general  FCS  design  objectives  defined  for  a  fighter  aircraft  currently  under 
development  in  Europe  are  flight  safety,  performance,  reliability,  maintainabil- 
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ity  and  expandability.  These  objectives  have  to  be  achieved  by  the  system  design 
while  remaining  within  the  following  design  constraints: 

o  system  mass,  space  and  power 

o  cost 

-  the  primary  aim  is  to  minimize  life  cycle  cost  over  an  in-service  lift 
of  25  years  /  6000  flying  hours  per  aircraft 

o  timescales 

o  operational  environment 

-  environmental  conditions  (thermal  range,  vibration,  shock) 

-  electromagnetic  compatibility,  lightning  protection,  NEMP, 
nuclear  hardening 

Reliability  and  maintainability  (including  testability)  are  to  be  given  equal 
priority  to  flight  safety,  performance  and  timescales  during  all  phases  of  a 
program. 

Utilization  of  low-power  devices,  advanced  VLSI  technology,  custom  monolithic 
analogue  microcircuit  technology  ( CMAM ) ,  ASIC,  surface  mount  technology  to¬ 
gether  with  innovative  approaches  to  aircraft  installation  design  and  methods 
are  major  prerequisites  to  incorporate  the  required  functionality  in  the  given 
constraints  (such  as  mass,  space  and  power  consumption)  of  the  FCS.  Software 
development,  verification,  validation,  and  maintenance  is  becoming  an  ever  in¬ 
creasing  part  of  aircraft  life  cycle  cost.  Advances  in  microelectronics,  the 
highest  possible  degree  of  standardization,  a  consistent  system  development  me¬ 
thodology  and  supporting  tools  (for  requirement  specification,  design,  imple¬ 
mentation,  maintenance)  dealing  with  the  entire  life  cycle,  of  which  development 
is  only  a  part,  can  collectively  lower  aerospace  electronic  system  life  cycle 
cost. 

FCS  computing  design  should  anticipate  needs  for  longterm  evolvability  of  both 
the  system  and  the  system  concept.  As  hardware  costs  continue  to  shrink  relative 
to  software  costs,  the  reusability  and  portability  of  the  system  concept  and  the 
software  is  going  to  be  increasingly  important.  System  development  should  be 
based  not  merely  on  a  loose  collection  of  good  ideas,  techniques  and  tools  but 
also  on  a  pervasive  methodology  approaching  emerging  technologies  and  new 
requirements  for  improvement  of  weapon  system  performance  in  a  system  oriented 
manner. 

FCS  should  be  kept  as  simple  as  possible.  Safety  unquestionably  suffers  whenever 
unnecessary  complexity  creeps  in  and  is  a  misguided  belief  in  complexity  as  a 
way  to  achieve  performance.  The  most  difficult  part  of  fault-tolerant  FCS  design 
is  mastering  the  complexity.  The  trend  towards  distributed  processing  with 
"smart"  sensors/actuators  offers  promise  because  it  decomposes  the  overall  com¬ 
plex  system  into  smaller,  comprehensible  subsystems  with  simpler  design  problems 
Since  the  functions  for  flight  controls  are  naturally  partitioned,  the  system 
can  easily  be  configured  into  a  distributed  arrangement  with  fixed  assignments 
of  tasks.  A  hierarchical  decentralized  controls  methodology  reduces  the  complex¬ 
ity  of  the  control  by  distributing  the  control  authority  to  local  controllers. 
This  allows  the  design  to  be  comprehensible  at  the  global  level  while  remaining 
optimal  at  the  local  controller-  or  subsystem  level.  This  concept  is  already  the 
baseline  for  an  A/C  currently  under  development,  where  an  IMU  (analytical  plat¬ 
form)  is  supervised  and  controlled  by  a  FCC  and  actuator  loops  are  digitally 
closed  by  dedicated  processor(s)  within  the  (multi-processor)  FCC.  When  "smart" 
actuators  become  available  due  to  advances  in  high  temperature  electronics  will 
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this  not  cause  a  change  of  concept  but  only  a  further  decomposition  of  system 
complexity.  Additional  merits  of  this  approach  are  enhanced  fault  tolerance  and 
opportunities  for  improving  the  performance/cost  for  the  life-cycle  of  the 
system. 

Designed  to  a  set  of  stringent  safety  requirements  the  FCS  must  be  free  of  any 
architectural  constraints,  provide  the  capability  to  accomodate  advanced  hard¬ 
ware  element  retrofits  to  expand  functions  and  add  subsystems  with  minimum 
impact  on  the  system. 

FCS  architectures  for  fighter  aircraft  in  service  are  characterized  by  non¬ 
standard  hardware  and  dedicated  hardwired  interfaces  which  impose  significant 
weight,  volume  and  power  penalties,  and  allow  little  freedom  for  growth.  The 
general  way  of  intra-lane  data  exchange  within  the  FCS  shall  be  realized  by  four 
simplex  standard,  time  multiplexed  data  buses,  endowing  the  FCS  with  a  high  de¬ 
gree  of  flexibility  combined  with  limited  wiring  expense.  The  selection  criteria 
for  STANAG  3838  is  based  on  reliability,  cost,  industry  acceptance  and  band¬ 
width.  The  address  limitation  of  31  remote  terminals  will  not  be  a  problem  for 
FCS  and  replacing  the  3838  bus  by  a  fibre  optic  equivalent  is  feasible. 

The  analysis  of  FCS  architectures  for  optimal  functional  partitioning,  i.e.  the 
definition  of  Line  Replaceable  Items  (LRIs)  has  to  minimize 

o  hardware  interconnections 

o  signal  interchange  and  the  related  timing  constraints 
o  failure  propagation  due  to  lack  of/erroneous  data 

o  modifications  required  for  future  LRI  enhancements  and/or  additions 
o  workload  for  fault  location  and  subsequent  maintenance  action. 

A  well  designed  computing  system  configuration  should  keep  the  complexity  of 
system  interconnections  to  a  minimum  with  the  constraints  set  by  data  links,  LRI 
size  and  fault  tolerance  requirements. 

The  first  ingredient  of  reliable  electronic  systems  is  a  reduced  chip  count. 

FCS  are  I/O  intensive  and  the  challenge  is  thus  to  minimize  interface  hardware 
and  wiring  mass  either  by  LSI  implementation  and/or  by  intelligent  ("smart") 
sensors/actuators.  Although  there  are  definite  trends  towards  distributed 
processing  it  will  probably  not  materialize  in  the  near  future  for  "smart” 
actuators. 

FCS  character  of  computation  exhibit  a  large  degree  of  regularity  (with  low 
complexity)  where  real  time  aspects  and  phase  lags  are  of  prime  importance.  A 
maximum  practical  percentage  of  functions  should  be  performed  by  program 
execution  rather  than  by  analogue  hardware  circuits. 

Parallel  processing  is  an  important  consideration  in  the  FCC,  with  the  implied 
requirement  that  tasks  are  partitioned  and  allocated  to  take  advantage  of  the 
inherent  concurrency.  Distributed  and  parallel  processing  offer  the  benifits  of 
smaller,  more  manageable  and  validatable  software  modules  which  are  physically 
as  well  as  functionally  independent. 

The  computing  system  configuration  must  take  into  account  the  flight  safety 
requirement  of  the  entire  FCS  (including  sensors  and  actuators). 

Reliablity  and  not  convenience  of  programming  was  the  primary  motivation  behind 
the  development  of  high  level  structured  languages.  Powerful  and  mature  develop¬ 
ment  tools  and  environments  will  improve  software  dependability  and  productivity 
by  enabling  engineers  to  focus  on  requirements  and  design  rather  than  on  coding. 


3.1  FCS  Description 

The  system  (Fig.  9)  is  defined  as  comprising 
o  Sensor  equipment  and  digital  computers 

-  Air  Oata  Transducers  (ADTs) 

-  stick  sensor  assembly,  pedal  position  sensor,  cockpit  switch  functions 

-  Air  Intake  Pressure  Transducers  (AIPTs) 

Inertial  Measurement  Units  UMUs) 

-  Flight  Control  Computers  (FCCs) 

o  FCS  primary  and  secondary  actuation  systems  including  the  actuators,  the 
control  surfaces  and  associated  pats  such  as  hinges,  bearings,  etc. 

and  performs  all  the  tasks  of  measurement,  computation,  primary  and  secondary 
control  surface  actuation  necessary  to  carry  out  all  manoeuvres  required  by  the 
pilot  or  mission  avionics  system. 

3.2  Flight  Control  Computer 

The  quadruplex  FCCs  are  the  main  controlling  element  of  the  FCS  and  have  to 
provide  the  computational  capability  as  listed  in  Table  2.  Table  3  summarizes 
the  FCC  hardware  characteristics.  Each  FCC  shall  be  identical  and  shall  contain 
the  necessary  software  and  hardware  to  operate  in  any  lane  of  the  FCS.  The  FCC 
multiprocessor  architecture  is  characterized  by  a  collection  of  cooperatively 
autonomous  computer  elements  which  are  based  on  the  local  processing  principle, 
i.e.  the  memories  and  peripheral  units  are  firmly  allocated  to  a  CPU  and  cannot 
be  addressed  by  external  processors.  Communication  shall  be  achieved  by  either 

a)  a  high  speed  parallel  MuTti-Master-Systembus 

b)  or  by  other  methods  provided  that  the  FCC  architecture  does  not  restrict 
data  flow  and  is  inherently  expandable. 

Task  distribution  between  computer  elements  has  to  be  partitioned  such  that 
they  will  be  almost  independent  of  each  other  as  far  as  function  is  concerned 
reducing  communication  between  the  tasks  as  much  as  possible  and  minimizing 
additional  transport  delay  (due  to  communication)  and  real-time  and  hardware 
overhead  to  support  concurrent  execution.  Static  assignment  of  tasks  to  pro¬ 
cessors  is  required  and  I/O  processing,  loop  closure  of  the  auto-throttle  actu- 
ator(s),  primary  and  secondary  actuators,  and  redundancy  management  have  to  be 
separated  from  control  law  processing  and  air  data  computation  to  provide  flex¬ 
ibility  for  changing  the  control  laws  during  life  cycle  and  allow  the  later  in¬ 
troduction  of  additional  autopilot  modes  with  minimum  disturbance  to  the  core 
program.  Task  scheduling  is  not  interrupt  driven  by  randomly  timed  events  and 
interrupt  sources  are  reduced  to  an  absolute  minimum  and  only  allowed  for 

a)  triggering  minor  frames  and/or  shorter  subframes 

b)  exception  handling. 

The  general  method  for  controlling  the  executive  sequence  is  by  use  of  a  time 
synchronized  (cyclic)  executive.  The  sequence  of  activities  to  be  performed  by 
a  processor  within  a  frame  (or  shorter  subframe)  is  predetermined  due  to  the 
implementation  of  a  static  preplanned  (nonpreemptive)  scheduling  mechanism.  The 
resulting  system,  while  relatively  easy  to  implement  and  to  validate,  is  exceed¬ 
ingly  inflexible  once  iteration  rates  and  task  selections  are  made.  Because  of 
the  performance  (not  effective  CPU  utilization)  and  flexibility  limits  of  the 
nonpreemptive  scheduling  mechanism  the  alternative  of  using  priority  based  (pre- 
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emptive)  periodic  scheduling  has  to  be  investigated  and  how  a  proof  of  correct¬ 
ness  of  the  cooperating  concurrent  processes  can  be  performed. 

To  reduce  development  and  support  cost,  a  single  processor  type  for  all  aircraft 
i  systems  is  highly  desirable.  In  order  not  to  constrain  hardware  design  by  equip¬ 

ment  suppliers  unnecessarily,  component  standardization  should  be  limited  to  the 
p  microprocessor .  Wherever  processor  type  standardization  is  required,  the  de- 

1  cision  on  the  particular  type  of  component  to  be  used  will  require  protection 

*  for  supply  and  support  of  the  product  for  the  life  of  the  aircraft  or  an  equip¬ 

ment  upgrade  path  to  be  identified  which  preserves  investment  in  system/SW  de¬ 
sign.  Comparing  the  suitability  of  different  processors  is  problematic  because 
1  many  variables  (including  commercial  conditions)  are  invoked  and  even  the 

’  criteria  by  which  they  are  judged  are  controversial  [8,  9,  10,  11], 

,  Control  functions  to  be  performed  in  the  FCC  in  the  future  are  becoming  more 

comprehensive  and  complicated  as  task  oriented  control  and  carefree  manoeuvering 
modes  are  fully  exploited.  The  multiprocessor  configuration  ensures  that 
>  sufficient  processing  throughput  is  available  as  well  as  allows  the  control 

tasks  to  be  partioned  into  convenient  modules. 

Frequently  used  software  functions  have  a  tendency  to  migrate  into  hardware  - 
possibly  via  firmware  as  an  intermediate  step.  Thus  some  of  todays  software 
issues  can  be  expected  to  continue  to  become  hardware  issues  in  the  future.  The 
software  features  that  are  particular  strong  candidates  for  hardware  realization 
in  the  future  include  voting/monitoring,  distributed  control  features  for  syn¬ 
chronization,  intercommunication  and  scheduling.  Scope  control  and  data  encapsu¬ 
lation  -  essential  in  modern  programming  languages  like  Ada  -  can  be  provided  in 
hardware  with  better  addressing  mechanisms  that  integrate  advanced  approaches  to 
protection,  eliminating  the  so  called  "semantic  gap"  of  the  von  Neumann  machine 
[12].  Objects  and  capabilities,  along  with  modularity,  will  contribute  t0 
reliability  due  to  a  fine  grain  of  protection  and  fault  containme  .. 

Recently,  considerable  attention  has  been  focused  or  Fib*,  machines  motivated 
primarily  by  its  low  hardware  requirements  and  claimed  higher  throughput.  As 
stated  in  [12]:  In  terms  of  protection,  however,  RISC  machines  are  a  step  back 
to  the  dark  ages  of  the  "pure"  von  Neumann  macnines.  Tl~ ■  -  is^ue  has  recently 
been  discussed  by  D.  Nelson  who  characterises  the  RISC  macnirr  by  using  Ralph 
Nader's  famous  slogan  "unsafe  at  any  speed". 

General-purpose,  single-chip  (monolithic)  digital  signal  processing  (DSP) 
devices  are  providing  new  and  expanded  applications  in  the  area  of  LVDT/RVDT 
signal  conditioning  and  digital  control  loop  closure  of  actuators. 

3. 3  Sensor  Interface 

The  sensor  interface  covers  the  sensors  necessary  to  meet  the  airframe  related 
requirements  as  well  as  those  to  meet  the  mission  related  requirements.  Below, 
only  the  former  is  outlined.  The  interface  to  the  latter  is  via  the  AVS  and  UCS 
bus  system.  The  analysis  of  the  functional  requirements  in  the  sensor  area  re¬ 
vealed  a  commonality  of  the  FCS  and  other  A/C  systems  for  air  data  and  inertia) 
data.  Both  low  accuracy  with  high  availability  and  high  accuracy  with  low  avai¬ 
lability  sensor  data  are  needed  in  the  FCS  for  guidance  _nd  control  functions. 
The  requirements  of  the  AVS  (e.g.  Displays,  Navigation,  Weapon  System)  and  the 
UCS  (e.g.  Engine  Control  Fuel  Gauging,  Warnings)  are  covered  by  those  of  the 
FCS.  As  the  objective  was  to  optimize  overall  installation,  hardware  required 
for  the  implementation  of  one  system  had  to  be  utilized  for  implementing  other 
functions.  This  led  to  a  centralized  ADS.  Apart  from  the  above  mentioned  advan¬ 
tages  with  respect  to  installation,  there  are  a  number  of  other  advantages  (e.g. 
Location  error  correction).  Structural  effects  made  it  necessary  to  measure 
inertial  data  for  the  AVS  and  the  FCS  at  different  locations  in  the  A/C. 
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Further,  a  central  IMS  would  not  have  been  weight  and  cost  optimal.  Therefore, 
a  high  accuracy/low  availability  system  being  part  of  the  AVS  and  a  medium 
accuracy/high  availability  being  part  of  the  FCS  was  chosen.  The  latter,  how¬ 
ever,  is  accurate  enough  to  provide  the  back-up  navigation  function. 

The  AOS  is  based  on  a  four  multi-function  probe  configuration  (skewed  sensor 
arrangement)  to  give  independent  measurement  of  pitot  and  static  pressure  and 
local  flow  angle  (see  Fig.  10).  Each  probe  is  combined  with  pressure  transducers 
and  16  bit  microprocessor  based  electronics  for  computation  and  BIT  to  form  an 
Air  Data  Transducer  Unit  (AOT)  avoiding  pneumatic  pipework  and  water  separators. 
The  ADT  measures  and  transmits  local  flow  angle  (phi)  and  indicated  static/true 
pitot  pressure  to  its  own  lane  FCC  via  a  simplex  STANAG  3838  FCS  bus  where  all 
air  data  compensation,  computing,  voting  and  monitoring  will  be  performed.  Probe 
heater  control  and  monitoring  is  performed  by  the  ADT. 

Each  ADT  is  supplied  with  semi -conditioned  power  from  the  appropriate  FCCs  to 
minimize  the  size  of  the  sensor  unit. 

The  FCS  inertial  measurement  system  consist  of  four  attitude  and  heading 
strapped  down  platforms.  The  sensed  A/C  rates  and  accelerations  and  various 
calculated  parameters  are  used  within  the  FCS  to  provide  artificial  stabilisa¬ 
tion  of  the  A/C  and  are  also  transmitted  by  the  FCS  to  other  systems  eg.  to 
support  backup  navigation.  The  FCS  inertial  measurement  system  forms  an  integral 
part  of  the  aircraft  inertial  measurement  system. 

Each  IMU  lane  consists  of  gyros,  accelerometers  and  associated  electronics  for 
signal  conditioning,  computation,  data  transmission  and  BIT  implementing  a 
strapped  down  attitude  and  heading  reference  system  by  measuring  linear  acceler¬ 
ation  and  angular  rates  in  all  three  body  axis.  From  these,  the  IMUs  calculate 
and  output  to  the  FCCs  on  a  lane  by  lane  basis  via  simplex  STANAG  3838  FCS  buses 
the  required  signals  (see  Fig.  11).  With  a  skewed  sensor  arrangement  the  number 
of  sensors  and  equipment  mass  can  be  minimized. 

Cockpit  and  switch  functions  (with  the  exception  of  Multi  Head  Down  Display  soft 
key  functions  and  autopilot  selections)  are  hardwired  to  the  appropriate  FCCs, 
and  they  provide  the  necessary  excitation  for  each  sensor/transducer .  The  con¬ 
siderable  number  of  FCS  signals  associated  with  the  cockpit  causes  the  airframe 
designer  problems  to  route  the  cables  through  the  cockpit  bulkheads  and  incurs 
wiring  mass.  A  four  lane  cockpit  interface  unit  (CIFU)  which  receives  pre¬ 
conditioned  power  from  the  FCCs,  and  interfaces  with  the  appropriate  STANAG  3836 
FCS  bus  can  incorporate  the  discrete  inputs/outputs  and  analogue  input 
functions.  The  integrity  implications  and  the  resultant  effect  on  mass  have  to 
be  investigated. 

3.4  Actuator  Interface  Configuration 

Direct  drive  valves  (OOVs)  represent  the  actuator  system  related  technology  to 
be  specified  for  fighter  A/C  currently  under  development.  DDV  benefits  occur 
primarily  because  of  the  simplified  interface  of  multiple  digital  signal  pro¬ 
cessing  channels  with  two  hydraulic  systems  (i.e.  effects  of  electrical  and 
hydraulic  failures  are  seperated),  reduced  electrical  wire  count,  substantial 
weight  savings,  the  inherent  simplicity  and  reliability  and  hydraulic  system 
savings  by  eliminating  EHV  null  flow  losses. 

The  simplest  actuator  design  utilises  a  single  stage  (linear  or  rotary)  DDV 
(see  Fig.  12).  Each  FCC  drives  one  lane  of  the  direct  drive  motor,  the 
mechanical  output  of  which  is  directly  connected  to  a  high  precision  hydraulic 
control  valve.  The  output  of  this  control  valve  is  connected  to  a  tandem 
hydraulic  ram,  thus  controlling  its  position.  The  position  of  the  hydraulic 
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control  valve  is  measured  by  four  LVDTs,  the  output  of  each  being  fed  back  to  a 
different  FCC  to  close  the  control  valve  position  loop.  Ouadruplex  voted  and 
monitored  ram  LVOT  feedback  singnals  are  used  to  close  the  main  ram  position 
loop.  Loop  closure  of  the  inner  and  outer  loop  will  be  digital  with  a  sampling 
frequency  of  320  Hz  and  80  Hz  respectively.  A  jammed  valve  must  be  detected, 
and  the  motor  drive  amplifier  has  to  be  capable  of  providing  enough  current  to 
overcome  the  valve  jamming  force.  Due  to  the  low  probability  of  a  jammed  valve 
occurring,  the  capability  to  overcome  the  jam  force  is  only  required  with  all 
four  electrical  control  lanes  operating  at  normal  aircraft  power  supply  voltage 
and  both  hydraulic  systems  functioning.  The  probability  of  loss  of  control 
valve  function  due  to  a  handover  failure  in  one  lane,  which  cannot  be  switched 
off,  followed  by  a  subsequent  failure  in  another  FCC  shall  be  reduced  to  less 
than  10-9/FH . 

Digital  control  loop  closure  provides  means  of  reducing  inner  loop  error  signal 
disparity  between  lanes  in  a  high  gain  actuation  system  by  low  rate  equalization 
of  control  valve  LVOTs,  thus  reducing  force  fight  in  the  DDV  and  gives  scope  for 
reduction  in  matching  requirements  (hence  cost)  of  the  position  transducer. 

Problem  areas  of  potential  concern  are  increased  electrical  power  levels,  EMI 
of  power  switching  electronics  and  magnetic  coupling  in  the  DDV.  Pulse  width 
modulation  allow  the  valve  driver  amplifier  to  act  as  a  switch  rather  than  as 
linear  (class  A)  amplifier,  thereby  improving  the  amplifier  efficiency  and 
reliability  as  a  result  of  the  lower  power  dissipation. 

The  speci f ication  of  actuator  interfaces  causes  the  airframe  manufacturer  pro¬ 
blems,  because  actuator  characteristics  and  its  controlling  FCC  influence  each 
other'  s  design  requirements.  Cross-company  definition  and  responsibility  pro¬ 
blems  are  to  be  solved  and  therefore  the  FCC  Supplier  and  the  actuator  Supplier 
have  to  cooperate  to  achieve  the  best  performance  of  the  actuation  systems.  The 
FCC  Supplier  has  to  provide  sufficient  information  about  actuator  loop  closure 
techniques,  to  enable  the  actuator  Supplier  to  design  a  test  set  with  represent¬ 
ative  simulation  of  the  actuator  drive,  feedback  demodulator,  digital  feedback 
paths  as  provided  by  the  FCC  actuator  interface,  so  that  representative  actuator 
performance  testing  can  be  executed. 

"Smart"  actuators,  i.e.  with  actuator  mounted,  or  local,  electronics  for 
actuator  loop  closure,  redundancy  management  and  BIT  are  a  technology  goal  to 
link  actuators  directly  to  the  FCS  buses  with  the  following  advantages: 

o  easier  to  specify  for  airframe  manufacturers 
o  actuation  system  can  be  purchased  from  one  Supplier 
o  system  integration  via  FCS  bus,  e.g.  electronic  or  optical 
o  low  weight  system 

o  improved  reliability 

o  reduced  system  vulnerability  to  lightning,  EMP.RFI 

o  reduced  demand  for  fibre  optic  sensors 

High  temperature  electronics  for  "Smart”  actuators  have  to  survive  in  an  un¬ 
controlled  environment.  GaAs  is  a  semiconductor  technology  for  environmental 
extremes  [13],  and  its  development  is  supported  by  DARPA  and  SDI  because  of  its 
vital  military  applications  (potential  for  high-speed  signal  processing,  low 
power  dissipation,  high  radiation  resistance). 

The  use  of  optical  encoders  to  measure  linear  and  angular  displacement  is 
limited  by  timescale  and  connector  density.  Fibre  optic  sensors  have  seen  much 
research  in  recent  years  aimed  at  reducing  system  vulnerability  to  lightning, 

EMP  and  RFI,  but  this  technology  is  not  mature  enough  to  be  used  for  A/C  under 
development. 
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3.5  Software 

The  necessity  of  using  tools  for  system  analysis,  software  requirement  analysis, 
software  development  and  maintenance,  which  allow  requirements  to  be  analyzed 
for  completeness  and  consistency  and  provide  support  fpr  development  phase  inde¬ 
pendent  activities  (e.g.  configuration  management,  project  management,  quality 
assurance,  documentation),  is  no  longer  disputed  even  in  the  practical  domain. 

An  Integrated  Project  Support  Environment  (IPSE)  has  to  be  built  up,  comprising 
a  set  of  tools,  dealing  with  the  entire  life  cycle.  The  IPSE  will  provide  inte¬ 
gration  of  the  tools  on  two  levels,  first  at  the  user  level  and  second  at  the 
data  level.  The  integration  at  the  user  level  will  provide  a  common  user  inter¬ 
face  to  the  tools,  which  have  been  fully  integrated  with  the  IPSE.  The  integra¬ 
tion  at  the  data  level  will  allow  different  tools  to  access  the  same  data  and 
allow  the  relation  ship  between  the  outputs  from  different  phases  of  the  soft¬ 
ware  life-cycle  to  be  recorded. 

It  is  essential  that  the  FCS  is  not  designed  in  isolation  from  other  systems, 
thus  each  system  has  to  follow  a  common  design  method  where  the  functional  and 
performance  requirements  are  conducted  in  a  phased  manner  following  a  design 
route.  All  output  documents  produced  at  the  end  of  a  phase  have  to  be  reviewed 
and  validated  as  an  overall  A/C  system  activity. 

System  analysis  is  divided  into  three  phases.  Phase  1  specifies  FCS  top  level 
requirements  and  interface  requirements  to  other  A/C  systems.  Phase  2  will 
produce  the  FCS  functional  requirements  and  the  Preliminary  Interface  Control 
Documents.  Phase  3  will  address  the  individual  LRIs  and  will  produce  for  these 
the  LRI  Processing  Specification  and  the  Interface  Control  Document  (ICO).  The 
output  documents  of  phase  3  will  be  given  to  the  selected  equipment  supplier. 

The  management,  development  and  production  of  the  procured  software  will  be  in 
accordance  with  software  standards  and  software  management  control  procedures 
(based  on  OOD-STD-2167)  specified  by  the  airframe  manufacturer.  The  equipment 
Supplier  starts  with  a  software  requirement  analysis  phase  and  produces  a  Soft¬ 
ware  Requirement  Specification.  A  detailed  description  of  the  software  phases 
lies  beyond  the  scope  of  this  article.  The  paper  by  Cavan o  [15]  discusses  from  a 
DOD  perspective  a  management  approach  to  achieving  high  confidence  software, 
highlighting  software  reliability  as  the  key  factor  and  emphasizes  that  the 
software  reliability  must  be  continuously  monitored  over  its  life  cycle. 

The  integrity  of  the  FCS  software  has  to  be  compatible  with  the  given  integrity 
requirement  for  the  system  and  is  regarded  as  class  1  (safety  critical). 
Currently  Assembler  is  the  language  used  most  for  FCS  software  implementation 
where  safety  and  performance  are  the  main  conflicting  requirements.  By  compari¬ 
son,  much  software  outside  the  safety  critical  area  has  long  been  written  in 
High  Order  Languages  (Jovial,  Pascal,  Ada).  Ada  directly  supports  such  vital 
software  engineering  concepts  as  data  abstraction,  information  hiding  and  modul¬ 
ar  design.  The  advantages  over  Assembler  are  well  known  and  need  not  to  be  ex¬ 
panded  upon  here.  To  take  advantage  offered  by  Ada,  a  careful  assessment  was 
undertaken  to  prove  whether  Ada  can  be  used  to  produce  an  implementation  of 
equivalent  integrity  to  an  Assembler  one.  To  obtain  an  answer  to  this  question 
three  major  problem  areas  had  to  be  addressed 

o  Is  Ada  able  to  solve  safety  critical  problems 
o  How  could  the  Ada-Compiler  integrity  be  assessed 

o  What  steDS  and  procedures  must  apply  in  an  Ada- implementation  for 

verificat.on  and  certification  purposes. 

To  answer  question  one  a  definition  of  safety  had  to  be  defined  which  was 
consistent  with  the  accepted  software  engineering  practice  for  current  FCS 
implementation  and  second,  based  on  this  definition  the  language  features 
defined  in  the  Ada  language  Reference  Manual  were  examined  with  regard  to 


whether  or  not  their  use  would  have  an  impact  on  this  safety  definition.  This 
examination  resulted  in  a  list  of  35  language  restrictions  to  be  imposed  when 
applying  Ada  to  safety  critical  areas.  The  obeyance  of  these  restrictions  can 
be  checked  for  each  program,  maybe  by  automatic  tools. 

The  Ada-Compiler  integrity  can  be  assessed  by  verifying  the  target  code  to  any 
demanded  degree  with  the  means  of  Code  Mapping  Charts  to  provide  full 
visibility  of  the  compilation  process. 

The  use  of  code  analysis  techniques  using  static  analysis  tools  allows  verific¬ 
ation  that  the  Ada  design  and  code  implements  the  functional  and  safety  speci¬ 
fication  of  the  initial  design.  Manual  compilation  of  target  code  by  use  of  Ada 
to  target  code  mapping  charts  demonstrates  the  visibility  and  correctness  of  the 
source  to  target  code  mapping  performed  by  the  compilation  process  and  thus 
gives  confidence  in  the  compiler  generated  target  code  and  in  the  compiler 
itsel f . 

The  processing  overhead  to  be  paid  for  Ada  generated  code  is  still  in  debate. 
Efficient  floating-point  Ada  target  code  generation  is  important  for  FCS  soft¬ 
ware  in  order  to  eliminate  the  need  for  fixed  point  arithmetic.  The  relatively 
high  number  of  fast  floating-point  registers  in  modern  floating-point  co¬ 
processors  makes  register  optimization  much  more  important  The  compiler  must 
schedule  register  use  over  the  entire  course  of  a  program,  paying  attention  to 
how  often  the  value  appears  in  the  source  code  as  well  as  how  often  it  will  be 
used  during  execution. 

The  software  of  less  complex  LRIs  (e.g.  ADT)  may  be  written  in  Assembler. 

3.6  Operational  Environment 

The  environmental  conditions  experienced  by  each  LR I  are  determined  by  its  lo¬ 
cation  in  the  aircraft.  Means  to  fulfill  the  structural  design  requirements  for 
vibration,  gun  fire  vibration  and  shock  are  well  known  and  need  not  to  expanded 
upon  here.  The  ability  to  operate  in  absence  of  a  cooling  medium  for  at  least  15 
minutes  is  required  and  this  event  has  to  be  indicated  to  the  pilot.  The  FCS 
equipment  and  their  installation  have  to  be  protected  against  lightning  strikes 
and  must  be  electromagnetically  compatible  with  other  A/C  equipment  ("internal 
compatibility")  as  well  as  be  capable  to  operate  in  a  substantial  external  radio 
frequency/electro  magnetic  environment.  A  production  testing  inspection  plan  has 
to  demonstrate  that  the  EMC  properties  will  be  maintained  during  equipment 
production. 

Design  to  protect  against  the  NEMP  threat  (EXO-  or  ENDO  NEMP)  is  basically  the 
same  as  designing  against  EMI  (external  CW  RF  fields)  or  lightning  protection. 
The  biggest  threat  to  the  FCS  computing  system  is  posed  by  Initial  Nuclear 
Radiation  (INR).  Shielding  against  these  penetrating  rays  is  completely  out  of 
question  because  approximately  5  cm  lead  would  be  required  to  reduce  the  prompt 
gamma  level  by  a  factor  of  ten.  In  general,  nuclear  hardening  techniques  are 
dived  into  two  classes: 

o  Intrinsic  Hardening  depends  mainly  on  the  exclusive  selection  of 

components  which  are  proven  to  meet  a  project  radiation  requirement.  This 
will  result  in  a  FCS  which  provides  uninterrupted  performance  in  the 
environment  specified. 

o  Extrinsic  Hardening  depends  on  the  use  of  only  a  minor  number  of 

“radiation  hard"  components,  i.e.  the  system  is  protected  by  utilizing 
architectual  means.  The  FCS  has  to  detect  the  nuclear  event,  must  take 
corrective  measures  against  latch  up  of  semiconductor  circuits  and  has  to 
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return  to  full  performance  (or  at  least  State  3)  after  a  specified  time 
interval . 

The  time  to  double  amplitude  (a  measure  of  how  rapidly  a  dynamic  system 
diverges)  of  a  CCV  fighter  aircraft,  which  is  inherently  unstable  over  a  larc,e 
part  of  the  flight  envelope,  is  in  the  order  of  0.2  sec.  The  majority  of  dis¬ 
crete  components  and  semiconductor  circuits  are  not  designed  with  any  INR  re¬ 
quirement  in  mind,  even  in  military  applications,  and  information  on  INR  hard¬ 
ness  of  available  Integrated  Circuits  is  extremely  limited.  Because  of  the  US 
SOI  programme  It  can  be  assumed  that  within  5  to  10  years  INR  hardened 
components  will  become  widely  available. 

3.7  Testability  and  Maintainability  Issues 

The  PCS  BIT  objective  is  to  detect  failures  either  as  they  arise  during  flight 
or  prior  to  flight  during  the  preflight  check,  and  to  ensure  that  the  system  is 
at  all  times  operating  within  defined  performance  limits.  Because  redundant 
systems  lend  themselves  to  BIT  by  their  very  nature,  a  concept  of  maximum 
coverage  is  to  be  developed  with  not  only  flight  operations,  but  also  test  and 
maintenance  activities  considered  from  the  start.  According  to  the  operational 
mode  of  the  aircraft  the  FCS  will  be  tested  by: 

o  Continuous  Built-In-Test  (CBIT) 

o  or  Initiated  Built-In-Test  (IBIT) 

IBIT  will  be  divided  into  three  operational  levels: 

o  Pre-Flight  Check  (PFC)  will  be  initiated  automatical ly  each  time  the  FCS 
is  powered  up  on  ground  and  comprises  purely  electronic  checks.  The 
actuators  will  be  maintained  in  safe  position. 

o  Actuator  Checks  will  be  carried  out  on  a  weekly  basis  (12  op  hr)  and  are 
conditional  on  successful  completion  of  the  PFC  and  hydraulic  pressure 
being  available. 

o  First  Line  Checks  will  be  used  to  investigate  noncritical  areas  of  the  FCS 
(for  diagnostic  reasons),  flight  critical  (at  600  hours  period  of  risk) 
sections,  which  cannot  or  need  not  be  checked  in  PFC,  and  also  to  operate 
interacti vely  with  other  aircraft  systems,  ground  crew  etc.  where  this  is 
impractical  within  the  constraints  of  PFC. 

The  three  IBIT  functions  are  to  be  designed  in  an  integrated  manner  but  will  be 
executed  in  accordance  with  the  FCS  maintenance/'servicing  concept.  However,  each 
level  may  serve  as  a  maintenance  test  depending  on  the  nature  of  maintenance 
action  required. 

FCS  CBIT  provides  failure  detection,  isolation  and  reporting  by  a  combination  of 
Cross-Lane  monitoring  and  In-Lane  monitoring.  Trend  monitoring  (preventative 
maintenance)  can  be  achieved  by  monitoring  the  number  of  occasions  that  the  in¬ 
dividual  voter/monitor  updown  counters  operate,  to  determine  those  signal  fail¬ 
ure  which  are  transient  in  nature  and  thus  may  fail  positively  in  the  future. 

The  FCS  is  part  of  a  virtual  integrated  on-board  test,- evaluation  and  recording 
system,  which  will  be  distributed  across  all  aircraft  electrically/electronic- 
ally  monitored  systems  in  order  to  minimize  false  alarms,  maximize  fault  isola¬ 
tion  and  identify  intermittent  failures.  BIT  failure  information  gained  from 
both,  CBIT  and  IBIT,  will  be  reported  as  it  occurs  to  an  Integrated  Monitoring 
and  Recording  System.  In  addition  this  information  is  also  retained  in  the  LRIs 
on  non-volatile  memory  and  can  be  accessed  via  the  data  bus  or  test  connector  at 
flight  line  or  shop  level. 


The  PCS  has  to  provide  the  necessary  test  interfaces  for  support  equipment  to 
give  test  assistance  throughout  a  project  life  cycle,  i.e.  FCS  development, 
integration,  aircraft  integration,  structural  coupling,  EMC  and  production 
aircraft  testing. 

Modularity  and  common  standards  improve  maintainability  and  reduce  acquisition 
costs  by  simplifying  the  development  of  off-the-shelf  items  that  can  be  inte¬ 
grated  into  future  systems.  The  US  Air  Force  has  established  the  Pave  Pillar 
avionics  architecture  [14]  that  allows  a  two-level  maintenance  concept  to  be 
implemented.  In  todays  standard  three-level  maintenance  concept  (flight  line, 
Intermediate  shop,  depot/factory)  with  removal/  replacement  of  LRIs  at  the 
flight  line  the  need  for  the  intermediate  shop  level  can  be  excluded  when  mod¬ 
ules  become  Line  Replaceable  Modules  (LRM).  The  merits  of  the  LRM  concept  with  a 
semi  permanent  installed  integration  rack  include  A/C  installation  improvements, 
reduced  weight  and  EMI  susceptibility,  and  ultimately  a  reduction  in  spare  in¬ 
ventories.  No  attempt  is  made  here  to  discuss  the  life  cycle  cost  aspects  - 
these  are  more  than  adequately  covered  in  the  Pave  Pillar  article  in  this 
special  issue. 

Artificial  intelligence  techniques  (Expert  Systems)  [19]  can  be  used  in  future 
for  an  integrated  diagnostic  application. 

4.  RESTRICTIONS 

Flight  Control  Systems  must  meet  stringent  specifications  of  flight  safety  and 
availability.  Conservative  design  practice  in  engineering  imposes  certain  re¬ 
strictions  upon  the  application  of  advanced  computer  hardware/software  and 
micro-electronic  technologies.  The  discussion  centers  around  two  specific  items: 

o  VLSI  testability  and  configuration  control 

o  Software  reliability 

While  VLSI  offers  numerous  opportunities,  it  also  introduces  a  number  of  new 
problens  for  FCS,  which  have  to  be  considered.  The  clearance  of  industry  stand¬ 
ard  (commercial)  microprocessors  and  other  complex  electronic  circuits  give  rise 
to  the  following  concerns: 

o  Commercial  definition  specification,  which  is  often  ambiguous 

o  Difference  between  hardware  and  documentation 

o  Subject  to  continuing  development,  e.g.  mask  sets  are  updated,  without  the 
manufacturer  informing  the  user. 

o  Changes  added  by  second  source  manufacturer 

o  Transient  faults  will  be  more  prevalent  because  extremely  low  circuit 
energy  level  will  make  devices  much  more  susceptible  to  external 
interferences 

o  Too  complex  for  totally  rigorous  test  in  all  possible  operating  conditions 

Theoretically,  neither  simulation  nor  testing  can  completely  verify  the  correct¬ 
ness  of  a  VLSI  circuit.  The  acceptance  problems  are  further  increased  due  to  a 
lack  of  a  formal  mathematical  specification  for  complex  instruction  set  com¬ 
puters  (CISC).  As  VLSI  designs  increase,  the  issue  of  correctness  grows  from 
an  Interesting  theoretical  question  into  a  practical  consideration  with  which 
equipment  Supplier  and  airframe  manufacturer  must  deal.  One  cannot  rule  out  the 
possibility  of  residual  hardware  design  faults  at  the  chip  level.  Of  grave  con- 
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cern  is  the  possibility  that  one  or  more  very  rarely  entered  processor  states 
might  represent  a  hazardous  generic  design  flow  and  that  such  a  state  might  be 
entered  into  (essentially  sumultaneously)  by  all  processors  in  all  redundant 
lanes  [7].  The  same  problem  can  show  up  with  ASICs,  where  the  equipment  Supplier 
is  responsible  for  the  testing  procedure  and  no  high-volume  customers  can  assist 
in  finding  errors.  This  fact  reinforces  the  importance  of  using  industry- 
standard  processors. 

Methods  of  alleviating  type  acceptance  problems  are  strict  configuration  control 
to  microprocessor-  and  other  VLSI  circutis  mask  level,  tracebility  of  each  batch 
of  components  used  and  robust  design  of  computer  architecture  to  detect/absorb 
unexpected  VLSI  behaviour.  MIL-STD  883C  production  does  not  qualify  one  standard 
of  mask  set,  although  CECC  90000  does. 

The  absence  of  credible  reliability  prediction  methods  for  safety  critical 
(class  1)  software  makes  the  FCS  reliability  analysis  questionable.  The  length 
of  time  under  test  and  the  small  samples  of  failure  observations  make  it  im¬ 
practical  to  assess  the  reliability  of  the  software  by  means  of  growth  models 
and  statistical  models  [18]. 

FCS  software  is  only  modestly  complicated.  The  key  principles  which  FCS  software 
must  be  based  on  are  simplicity  and  visibility.  These  principles  must  be  mani¬ 
fested  within  the  specification  and  production  process  as  well  as  within  the 
products  (reports)  generated  during  the  different  development  stages.  The  term 
"simplicity"  does  not  mean,  that  the  overall  system  complexity  must  not  proceed 
some  simple  level,  but  it  does  mean  that  on  each  specific  stage  the  relevant 
information  can  be  simply  surveyed  and  reviewed  by  human  analysts.  In  order  to 
achieve  the  required  quality  standard  an  intensive  control  of  the  software 
production  procedures  is  indispensible  including  clear  and  thorough  definition 
of  requirements,  extensive  testing  and  design  audits,  detailed  documentation, 
and  rigorous  production  and  configuration  control. 

In  practice  of  course  no  matter  how  carefully  the  software  is  designed  it  is  im¬ 
possible  to  establish  that  it  is  completely  error  free  since  the  large  number  of 
possible  states  preclude  exhaustive  testing  and  the  statistical  analysis  methods 
used  in  hardware  design  are  not  applicable  to  software.  Since  we  know  of  no  sa¬ 
tisfactory  way  to  estimate  the  probability  that  a  software  module  is  incorrect, 
we  are  forced  to  try  to  guarantee  that  the  software  is  indeed  correct. 

A  "Proof-of-Correctness"  method  [20]  for  validating  software  is  being  invest¬ 
igated  by  SRI  Inc.  as  part  of  the  SIFT  Program.  This  methodology  employs  a  hier¬ 
archy  of  design  specifications  from  very  abstract  description  of  system  function 
down  to  actual  implementation,  that  can  be  proved  via  the  techniques  of  mathe¬ 
matical  logic  (predicate  calculus).  The  most  abstract  design  specification  can 
be  used  to  verify  that  the  system  functions  correctly  and  with  the  desired  re¬ 
liability.  A  succession  of  low-level  models  refine  these  specifications  to  the 
actual  implementation,  and  can  be  used  to  demonstrate  that  the  implementation 
has  the  properties  claimed  at  the  abstract  design  specification.  It  must  be 
noted  that  the  SIFT  proof  of  correctness  only  covers  the  operation  system  and 
not  the  application  domain.  This  technique  is  also  not  readily  understandable  to 
the  engineering  community  and  formal  specification  with  proof  of  correctness  for 
real  flight  control  systems  may  still  be  years  off. 

In  practice  very  small  and  simple  software  modules  must  be  used  which  are  easy 
to  verify  and  it  is  hoped  that  by  such  techniques  the  required  high  integrity 
can  be  achieved. 

Current  trends  will  increase  the  problem  because  VLSI  circuits  are  just  as 
complex  as  software. 
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5.  FUTURE  FLIGHT  CONTROL  SYSTEMS 
A  scenario  which  is  characterized  by 

o  a  threat  due  to  an  enemy  which  outnumbers  the  own  forces  and  increasingly 
improves  the  performance  of  his  aircraft, 
o  the  need  to  minimize  the  cost  of  ownership 

requires  future  weapon  systems  to  meet  stringent  requirements  which  entend  the 
field  of  classical  flight  control  to  the  field  of  flight  guidance. 

5.1  Weapon  System  Requirements 

The  need  for  a  better  survivability  drives  future  aircraft  to  operate  at  even 
lower  altitudes  for  a  longer  part  of  the  mission  than  today's  and  to  avoid  the 
usage  of  active  (i.  e.  emitting)  sensors.  The  requirement  to  improve  weapon 
system  effectiveness  Involves  day/night  and  all  weather  operation,  the  capa¬ 
bility  of  the  weapon  system  to  fight  several  targets  at  the  same  time,  to  ope¬ 
rate  jointly  with  other  aircraft  and  ground  stations,  and  to  maximize  the 
mission  success  rate.  An  optimal  weapon  system  performance  can  only  be  achieved 
if  the  pilot  is  relieved  of  tasks  which  are  better  performed  by  the  machine.  The 
goal  is  to  allow  him  to  concentrate  on  tactical  decision  making.  Further  weapon 
system  requirements  are  an  enhancement  of  the  operational  availability  and  a  re¬ 
reduction  in  life  cycle  costs  by  improving  reliability,  maintainability  and 
testability.  Finally,  the  number  of  aborted  missions  due  to  system  failures  has 
to  be  minimized. 

The  resulting  requirements  for  the  computing  configuration  of  a  future  guidance 
and  control  system  are 

o  calculation  of  a  mission  optimal  demanded  flight  path  taking  into  account 
the  performance  of  all  the  subsystems  involved 

o  contribution  to  an  optimized  performance  of  the  air  vehicle  including  air¬ 
frame,  flight  control  system,  engine  and  other  airframe  related  systems 

o  system  partitioning  such  that  each  subsystem  can  be  optimized  with  respect 
to  performance,  weight,  volume  and  power  consumption  and  maintenance  with¬ 
out  affecting  other  subsystems 

o  functional  subsystem  integration  such  that  the  resulting  system  at  a 
higher  level  is  optimized  with  respect  to  performance,  safety  and 
availability 

5.2  Trends  in  Future  Guidance  and  Control  Systems 

Flight  control  system  changes  are  evolutionary.  While  micro-electronic  techno¬ 
logy  will  achieve  further  improvements  as  listed  below,  this  will  not  lead  to 
FCS  concepts  that  are  radically  different  from  those  outlined  in  section  3. 

The  trend  to  computing  conf igurations  with  a  distributed  arrangement  of  elements 
with  a  fixed  assignment  of  tasks  is  most  likely  to  continue.  The  communication 
between  these  elements  will  be  via  standardized  interfaces.  This  allows  to  spe¬ 
cify,  develop  and  test  each  element  with  a  minimum  inpact  on  the  overall  system. 
By  making  the  subsystems  intelligent,  i.e.  provision  with  computational  power 
performance,  weight,  maintainability  etc.  will  be  improved.  This  has  partly  been 
achieved  in  the  sensor  area  but  not  yet  for  actuators  due  to  availability  of 
of  suitable  components.  Although  today  the  actuators  are  controlled  by  dedi¬ 
cated  microprocessors  located  in  the  FCC,  the  above  mentioned  improvements  are 
not  possible  due  to  interface  restrictions.  Local  data  processing  for  example 
example  could  allow  the  implementation  of  active  flutter  damping,  thus  reducing 
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weight  and  raising  bandwidth.  The  local  storage  of  calibration  data  and  auto¬ 
matic  LVOT  adjustment  by  going  through  a  learning  process  would  improve  main¬ 
tenance  and  reduce  life  cycle  cost.  Also,  the  degree  of  redundancy  can  then  be 
be  adjusted  individually. 

The  weapon  system  requirements  outlined  in  section  5.1  will  lead  to  a  functional 
integration  of  systems  in  two  areas: 

o  vehicle  management 

o  integration  of  the  vehicle  with  the  avionic  sensor  and  mission  system 

The  main  task  here  is  a  partitioning  into  functional  blocks  and  the  definition 
of  a  topology  so  that  the  resulting  integrated  system  meets  the  performance  and 
availability  requirements.  As  tasks  which  were  previously  done  by  the  pilot  are 
absorbed  into  the  machine,  this  will  result  in  changes  to  the  man-machine  inter¬ 
face.  Work  in  the  future  will  concentrate  on  optimizing  the  amount  and  type  of 
information  conveyed  to  the  pilot  and  on  techniques  of  transforming  pilot's 
decisions  into  appropriate  actions  of  the  machine. 

5.3  Enabling  Technologies  and  Tools 

The  rapidly  evolving  micro-electronic  technology  continuously  affords  new 
opportunities  in  ECS  concepts  while  at  the  same  time  posing  new  cnallenges  for 
the  effective  realization  of  its  potential.  Several  prospective  future  trends 
in  technology  are  summarized  here: 

o  Great  increase  in  the  processing  power  of  computer  components  (32  bit 
processors  with  floating-point  arithmatic  on  chip,  DSP,  microprocessors 
optimized  for  artificial  intelligence  languages) 

o  Great  improvement  in  cost  and  performance  among  all  electronic  integrated 
circuits,  surface  mounted  packaging,  fibre-optics 

o  Improved  computer  architectures  (object-oriented) 

o  Electronics  for  environmental  extremes  (temperature,  I  NR )  will  be 
available 

o  Improved  aircraft  installation  designs  (semi  permanent  installed 
integration  rack  assembly,  LRM  concept) 

o  Substantial  increase  in  bandwidth  of  bus  systems  (STANAG  3910) 

o  More  experience  with  distributed  systems 

o  Improved  understanding  of  software  engineering  principles 

o  Improved  fault  tolerant  system  design  methods  (including  analytical 
redundancy) 

o  Improved  tools  for  requirement  specification  and  software  design 

o  New  methodologies  (formal  specification)  for  verification  and  validation 

of  FCS 

o  More  experience  with  artificial  intelligence  techniques  (expert  systems 
for  real-time  control,  verification  and  validation  of  expert  systems) 

We  also  have  to  consider  what  research  areas  not  currently  central  to  the  FCS 
application  are  likely  to  emerge  in  the  next  five  or  ten  years  and  what  their 
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expected  impact  is.  The  functional  complexity  of  future  guidance  and  control 
systems  requires  the  application  of  a  strict  methodology  for  all  phases  of  the 
equipment  life  cycle.  Today,  a  phased  development  process  has  been  established. 
Tools  and  techniques  from  the  enabling  technologies  above  have  to  be  identified 
and  implemented  which  support  this  development  process. 


6.  SUMMARY  AND  CONCLUSIONS 


In  the  course  of  this  paper  we  have  first  analyzed  the  requirements  and  then 
examined  the  design  considerations  of  present  and  future  FCS  computing  sub¬ 
systems.  The  flight  control  computing  requirements  result  from  the  weapon  system 
carrier  functions  and  the  avionic  system  functions.  The  complexity  and  varity  of 
tasks  that  flight  control  systems  are  called  upon  to  perform  has  been  steadily 
increasing.  A/C  subsystem  integration  and  modularity  will  become  the  governing 
concept. 

With  the  mentioned  35  language  restrictions  to  be  imposed  Ada  can  be  used  for 
flight  control  implementation. 

Nuclear  hardening  will  become  one  of  the  biggest  problems  for  FCS  electronic 
subsystems  to  be  solved. 


Strict  configuration  control  of  VLSI  mask  sets  and  robust  computer  design  can 
alleviate  type  acceptance  problems.  Formal  specifications  with  proof  of  correct¬ 
ness  are  still  years  off. 


Future  weapon  system  requirements  will  be  driven  by  an  increased  threat  and  the 
need  to  minimize  the  cost  of  ownership. 


The  trend  towards  distributed  rocessing  is  most  likely  to  continue  because  it 
decomposes  the  overall  «  s+  ,  into  smaller  comprehensible  subsystems.  System 
integration  can  be  achieved  by  a  hierarchical  decentralized  control  method¬ 
ology. 

Physically,  the  computing  system  will  be  based  on  standardized  LRMs . 
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Table  1 :  Definition  of  Operational  States 


Operational 

State 

Delinitions 

(MIL-F-9490D) 

Functions 

Performances 

1 

Normal  operation 

1  S  AS /CAS 

2  Configuration 
control 

3  Carefree 
manoeuvring 

4  Baals  autopilot 

5  Automated 
functions 

•  Full  performance  within 
operational  envelope 

tl 

Restricted  operation 

SAS/CAS 

Functions  2-5  partially 
inhibited  (failed) 

(not  design  criteria) 

•  Degraded  mission 
performance 

•  Ftestricted  flight  envelope 

•  Increased  pilot  workload 

III 

Minimum  safe 
operation 

SAS/CAS 

Minimal  path  of  safety 
critical  function 

•  Loss  of  mission  performance 

•  High  pitot  workload  -  sale 
lor  landing 

IV 

Controllable  to 
an  evacuable  flight 
condition 

SAS/CAS 

Functions  lime 
limited  (sec!) 

•  Satisfactory  for  ejection 

V 

Catastrophic  condition 

Immediate  loss  of 
controllability 

— 

Table  2:  Flight  Control  Computer  Computational  Capabilities 

The  FCC  has  to  provide  the  following  computational  capabilities: 

o  the  interlane  communication  required  to  implement  the  FCS  redundancy 
management 

o  to  control  BIT  functions  at  the  level  of  inflight,  preflight  and  first 
line  tests  to  verify  that  the  FCS  is  capable  of  meeting  satisfactory 
performance  requirements  and  fault  isolation 

o  to  implement  the  mode  logic  and  the  control  laws  required  by  the  primary 
functions  and  secondary  actuation  systems 

o  for  the  air  data  processing 

o  the  BC  interface  to  control  the  serial  digital  intralane  communication 

(simplex  STANAG  3838  bus) 

o  the  interfaces  to  implement  the  primary  and  secondary  actuator  control 
loops  and  the  interface  with  the  auto- throttle  actuator! s) 

o  the  required  analogue  and  discrete  I/O  interfaces  for  the  FCS  related 
cockpit  functions  and  the  capability  to  control  the  proper  sequencing 

o  to  service  the  STANAG  3838/3910  RT  to  the  Avionics  and  Utilities  buses 

o  to  provide  preconditioned  power  for  ADT 

o  to  service  for  accident/incident  data  recording 

o  the  interfaces  to  support  equipment  (e.g.  Flight  Test  Data  Acquisition 
Unit  for  the  development  and  flight  test  activities) 

o  a  software  controlled  frequency  signal  generator  for  investigation  of 
flying  qualities  (frequency  response  measurement,  identification  of 
aerodyanamic  stability  and  control  parameters) 
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Table  3:  Flight  Control  Computer  Hardware  Characteristics 

Computer  Architecture  Multi-processor  system 

CPU  =  4  industry  standard  32  bit 

microprocessors  with  floating  point 
co-processors 

EPROM  >  320  K  bytes 

RAM  >  64  K  bytes 

Nonvolatile  RAM  4  K  bytes 

Interface  Cross  Channel  Data  Link  (CCDL)  with 

0.8  x  10exp.5  data  words/sec 
simplex  STANAG  3838  BC 
dual  redundant  standby  STANAG 
3838/3910  RT 
RS  422  Test  Interface 
50  LVDT/RVDT  Signal  Conditions 
14  DDV/EHSV  Amplifiers 
70  discrete  I/Os 
comprehensive  BIT 

Growth  potential  50  %  spare  memory 

30  7.  spare  I/O 

50  7.  throughput  for  control  law,  air  data  etc. 

30  '/.  throughput  for  I/O  processing 

Environmental  Ability  to  operate  in  absence  of  cooling  medium  for 

>  15  minutes 

Power  120  W  (excluding  power  supplied  to  external  devices) 

MTBF  >  2500  hours 

Packaging  1/2  -  3/4  ATR  short 

Weight  10  -  11  kg 
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Pilot  interpreted 
Integration 


Automated 

Integration 


Pig.  7 i  Schematic  of  Automated  Functions 


Operational 


Fig.  8:  Relation  between  Operational  States  and 
safety/mission  requirements 
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SUMMARY 

The  purpose  of  this  paper  is  to  highlight  the  reliability  features  of  the  CHF(*)  AIR  embedded 
computer  supporting  Its  operational  software.  This  computer  was  designed  to  meet  the  requirements  of  the 
ACE(* ) /RAFALE  D  aircraft.  For  this  reason,  it  has  to  be  highly  dependable,  to  satisfy  severe  physical 
requirements  (sice,  weight,  power  consumption,  etc.)  and  to  support  real-time  software  execution  (this 
software  being  written  in  high-level  languages  such  as  Ada(3)  and  LTR3  (a  French  Paacal-llke  real-time 
language). 

The  general  structure  of  the  computer  is  first  presented,  emphasis  being  placed  on  the  technologi¬ 
cal  choices  (for  example,  the  use  of  ASICs  :  Application  Specific  Integrated  Circuits).  The  various  protec¬ 
tive  twchanisms  provided  at  the  level  of  the  machine  (hardware  and  microcode)  are  then  presented  :  data 
access  control  and  code  execution  control.  Finally,  a  short  presentation  of  the  software  production 
environment  is  given. 

In  conclusion,  the  compromises  made  between  operational  dependability  and  performance  characteris¬ 
tics  are  summarized. 

INTRODUCTION 

The  production  of  on-board  computers  is  fraught  with  numerous  and  contradictory  requirements. 
Operational  dependability  certainly  constitutes  one  of  the  higher-priority  requirements  since  missions 
assigned  to  the  software  sre  covering  ever  Increasingly  critical  sectors  (weapons  management,  countermeasu¬ 
res,  flight  controls,  etc.).  The  presented  CMF  AIR  computer  constitutes  the  airborne  version  of  the  CMF 
range  of  computers  developed  under  the  auspices  of  the  French  DGA  (**).  In  this  respect,  It  is  certainly  the 
computer  of  the  CMF  range  required  to  satisfy  the  most  severe  requirements.  In  particular.  It  must  meet  the 
requirements  defined  for  the  mission  computer  of  the  ACE/RAPALR  D  aircraft  which  include  : 

-  operational  dependability  (but  a  lesser  degree  than  a  f light-control  management  computer,  for 
example) , 

-  available  space,  weight  and  power  consumption, 

-  high  computing  power, 

-  ease  of  extension, 

-  comprehensive  Instruction  set,  due  to  the  variety  of  functions  that  have  to  be  performed. 

The  design  options  of  the  CMF  AIR  computer  therefore  necessarily  result  from  a  compromise 
attempting  to  meet  all  these  requirements  as  explained  below. 


CHAPTER  l  :  GENERAL  STRUCTURE  OF  THE  COMPUTER 

The  CMF  AIR  computer  consists  essentially  of  a  central  unit,  an  input-output  system  and  a  power 
supply.  This  structure  is  illustrated  In  Figure  1  in  a  monocomputer  configuration.  It  should  be  noted  that 
In  order  to  meet  the  requirements,  a  bicomputer  solution  is  proposed,  simultaneously  providing  the  compu¬ 
ting  power  and  the  high  degree  of  reliability  Which  are  required  by  the  mission. 


*  CMF  :  Calculator  Mllttalre  Pranqals  -  French  Military  Computer 

3  ACE  :  Avion  de  Combat  Huropben  -  European  Combat  Aircraft 

3  Ada  :  Registered  trademark  of  Dod/AJPO  (Ada  Joint  Program  Office) 

4  DGA  :  Obligation  Gbnfrale  I  1’ Armament  -  French  Ministry  of  Defense 
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The  central  unit  ta  organised  around  two  communication  paths  : 

-  the  private  hue,  to  which  are  connected  : 

•  the  CM?  AIR  processor 
.  the  data  aeaory 

•  the  clock  systee 

.  the  Interfaces  to  the  private  bus  extension  and  the  VME  bus 

-  the  Instruction  bus  which  links  the  CM?  AIR  processor  to  the  Instructions  memory. 

1.1  CMF  AIR  FROCKS SOI 

A  micro- programmed  solution  has  been  chosen.  Halted,  for  efficiency  concerns,  to  one  level  of 
micro-programming.  The  alcro-lnatructlon  format  is  160  bits. 

A  four  level  pipeline  structure  la  lapleaented,  each  level  corresponding  to  one  of  the  four  aain 
functions  of  the  CM?  AIR  processor  : 

-  instruction  sequencing, 

-  fix/float  operators, 

-  address  generation, 

-  memory  management  (for  both  the  instruction  and  the  private  bus). 

The  rationale  for  this  organization  Is  to  provide  : 

-  a  simple  (then  efficient)  architecture, 

-  a  high  level  of  functional  parallelism  between  the  address  generator  and  the  fix/float  operator, 

-  protection  against  a  pipeline  desactlvatlon  when  a  control  statement  Is  executed, 

-  discrimination  between  Instruction  and  data  flows, 

-  deterministic  execution  times. 

1.2  OTHER  CENTRAL  UNIT  COMPONENTS 

The  private  bus  management  Is  of  master/slave  type  under  the  control  of  the  CMF  AIR  processor 
address  generator. 

The  clock  systma  is  In  charge  of  the  time  reference  at  the  system  level.  It  also  supports 
execution  of  “delay"  statements  at  the  application  level.  The  clock  system  ta  equipped  with  a  "watch-dog" 
device. 

The  Interface  to  the  (militarized)  VME  bus  controls  exchange  of  data  on  this  bus.  It  also  provides 
access  to  the  private  bus  and  to  the  data  memory  when  requested  by  the  I/O  controllers. 

1.3  TECHNOLOGICAL  CHOICES 

The  central  unit  has  been  structured  In  functional  blocks  which  are  lapleaented  In  several 
Application  Specific  Integrated  Circuits  (ASICs).  These  functional  blocks  are  listed  below  : 

-  instruction  sequencing, 

-  program  counter  aanageaent, 

-  Instruction  memory  management, 

-  address  generation, 

-  execution  processor, 

-  memory  management, 

-  clock  systea, 

-  real-time  management, 

-  timers, 

-  watch-dog. 


Interface  to  VME  bus 
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The  uee  of  ASIC*  and  Che  choice  of  C-MOS  technology  lead  Co  Implement  Che  whole  central  unit  In  a 
single  macro-hybrid  on  a  1/2  ATR  board*  The  overall  consumption  la  20  watts.  A  significant  benefit  which 
derives  from  these  technological  choices  Is  to  ensure  a  high  reliability  at  the  component  level  (high 
degree  of  Integration  and  low  consumption). 

1.4  nmoreiBiLiTT 

An  essential  feature  of  the  selected  design  is  to  provide  a  high  level  of  extensibility  : 

-  at  the  memory  level  through  the  private  bus  extension, 

-  at  the  processing  level  by  the  possibility  of  using  several  central  units  In  a  multi-processor 
architecture. 

CHAPTER  2  :  IE LIABILITY  FEATURES 

It  Is  mainly  at  the  level  of  the  logic  machine  that  specific  mechanisms  have  been  designed  and 
Implemented  for  Improving  operational  dependability.  The  general  structure  of  this  logic  machine  Is 
described,  followed  by  a  detailed  description  of  the  protective  mechanisms. 

2.1  (SHORT  ORGANIZATION 

The  memory  Is  organized  Into  the  following  three  types  of  zones  : 

-  data  zones, 

-  code  zones, 

-  system  zones  (e.g.  environment  of  a  task). 

System  sonea  are  entirely  administered  by  the  machine  and  invisible  to  the  user. 


of  the  following  five  types 


-  local  zones  containing  the  local  data  of  the  blocks,  procedures  and  processes  and  parameters 
passed  per  value  ;  these  zones  are  always  allocated  dynamically, 

-  visible  and  Internal  zones  containing  the  visible  (or  Internal)  data  of  the  modules  ;  these  zo¬ 
nes  are  always  allocated  before  the  start  of  application  software  execution  ; 

-  heap  zones  containing  the  data  created  dynamically  and  addressed  by  pointers  (Instruction  NEW), 

-  parameter  zones  containing  the  descriptors  of  the  addressable  parameters  (dynamically  allocated 
zones), 

-  static  zones  containing  the  remaining  data  structured  Into  zones  and  allocated  before  the  start 
of  application  software  execution. 

All  these  cones  are  addressed  by  means  of  a  base  and  displacement,  with  the  exception  of  the 
parameter  zones  which  are  addressed  by  means  of  a  base  and  parameter  number. 

All  the  bases  are  automatically  controlled  by  the  machine  (hardware  and  system  software). 

A  base  contains  the  following  Information  : 

-  zone  start  address, 

-  length  of  zone, 

-  zone  type  and  access  rights. 

Highly  efficient  execution  checking  Is  achieved  by  comparing  this  Information  with  the  operand 
access  paths. 

The  code  cones  contain  the  whole  of  the  program  code  (procedures  and  processes)  executed  In  the 
modules  (one  zone  per  module).  Each  code  zone  Is  addressed  by  a  base  which  specifies  the  start  address  and 
length  of  the  zone.  This  base  Is  used  for  initializing  the  program  counter  at  each  entry  Into  the  module  or 
at  each  task  activation.  This  structure  allows  highly  effective  checking  of  program  counter  evolution. 

2.2  PROTECTIVE  « CHAN I  SMS 

These  mechanisms  are  provided  by  the  logic  machine  (hardware  and  microcode).  They  apply  to  data 
access  and  code  execution. 

2.2.1  Data  access  checks 

1)  Address  checks  :  these  dynamically  verify  that  an  object  has  been  correctly  allocated  within 
the  zone  assigned  to  It.  These  checks  make  use  of  the  zone  length  end  overflow  information  and 
can  raise  s  ZONEjOVERPLOW  basic  exception. 

2)  Access  rights  checks  :  the  data  are  assembled  within  zones  by  access  types,  thereby  maklag  It 
possible  to  check  dynamically  these  access  types. 
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Access  rights  ar«  tha  following  : 

-  for  local  aonas  :  rsad  and  write,  read  and  write  Halted  to  generation  of  the  declarative 
part  or  tranaaiaalon  of  the  parameters  and  then  read  only,  write  only, 

-  for  visible  zones  :  read  and  write,  read  and  write  Halted  to  generation  and  then  read  only, 
read  and  write  froa  inside  the  aodule  and  read  only  froa  outside  the  module. 

These  checka  may  raise  an  ILLEGAL_ZONE_ACCESS  basic  exception. 

3)  Constraints  checks  :  these  checks,  contrary  to  those  described  above,  are  performed  by  the 
software  (code  generated  by  the  coapller). 

They  are  performed  when  accessing  the  operands  and  use  coapar  Ison  operators.  An  exaaple  of 
such  checks  is  the  verification  of  value  Halts  specified  in  language  LTR3  or  Ada.  These 
controls  are  likely  to  raise  a  NON_VERIPIED_CONSTRAXNT  software  exception. 

It  should  be  noted  that  the  basic  exceptions  are  processed  by  the  logic  machine  while  software 
exceptions  are  processed  by  the  application  software. 

2.2.2  Code  execution  checka 

1)  Address  checks  :  branch  or  internal  procedure  call  Instructions  cannot  modify  the  current  base 

(external  procedure  calls  and  systee  calls  only  have  thia  possibility).  It  Is  thus  easy  to 
c^eck  if  chu  counter  overflows  the  code  zone  of  the  current  module.  In  this  case,  a 

CODE_ZONE_OVERFLOW  exception  is  raised. 

2)  Branch  checka  :  dynamic  monitoring  of  sequence  breaks  is  performed  by  the  machine  by  means  of 
the  following  aechanlsm  : 

-  any  procedure  or  service  call  must  result  in  s  procedure  start  Instruction.  If  this  Is  not 
the  case,  the  I LL 8GAL_PR0CE DU RE_C ALL  basic  exception  is  raised.  This  exception  is  also  raised 
if  a  procedure  start  instruction  is  encountered  In  sequence  or  following  a  branch, 

-  any  branch  must  be  to  a  LABEL  instruction.  If  this  Is  not  the  case,  an  ILLEGAL_BRANCH  basic 
exception  Is  raised  (a  LABEL  Instruction  encountered  In  sequence  has  no  effect), 

-  any  exception  referred  to  the  software  must  activate  an  exception  handler  (standard  or  defi¬ 
ned  by  the  application  software),  necessarily  starting  with  Instruction  OPENH.  If  this  is  not 
the  case  the  ILL  EG AL^_H ANDL  E  R  basic  exception  Is  raised.  This  exception  la  also  raised  If  the 
handler  start  Instruction  OPENH  Is  encountered  In  sequence  or  following  a  branch. 

3)  Procedure  checks  :  the  presence  of  a  procedure  start  Instruction  Is  obligatory  as  the  first 
Instruction  to  be  executed  following  the  execution  of  a  procedure  call  instruction.  If  this  la 
not  the  case,  the  ILLEGAL_PROCEDURE_CALL  basic  exception  Is  raised. 

In  addition,  differentiation  between  procedure  start  instructions  at  the  start  of  an  Internal 
procedure  and  at  the  start  of  an  external  procedure  makes  It  possible  to  check  that  an  Internal 
procedure  has  not  been  called  from  outside.  This  check  can  raise  the  ILLEGAL__PROCEDURE_CAl  L 
basic  exception. 


CHAPTER  3  :  SOFTWARE  ENGINEERING  ENVIRONMENT 

Software  executed  on  the  CMF  AIR  computer  will  be  primarily  written  In  Ada,  which  by  Itself  ensu¬ 
res  a  high  level  of  reliability.  Indeed  Ada  has  been  designed  specifically  for  embedded  software  and  featu¬ 
res  such  as  types,  packages,  exceptions,  range  of  values  and  others  are  specially  suited  to  the  writing  of 
highly  reliable  software. 

But  moreover,  correctness  of  the  software  can  be  obtained  through  the  use  of  tools,  preferably 
Integrated  In  a  software  engineering  environment. 

Such  an  environment  already  exists  for  the  CMF  AIR  software  :  the  ENTREPRISE  environment,  deve¬ 
loped  by  the  DEI(5).  ENTREPRISE  Is  based  on  UNIX  and  Includes  an  'object  management  system'  which  Is  the 
repository  for  source  and  object  codes.  ENTREPRISE  also  Includes  LTR3  coding  tools  and  a  syntactic  editor. 
Access  control  Is  supported  ;  access  rights  attached  to  users  are  checked  each  time  an  access  to  an  object 
la  made. 
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DEI  :  Direction  Electronlque  et  Informatlque  is  a  division  of  the  French  DGA  (Ministry  of  defence) 
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But  software  reliability  haa  to  be  'constructed'  all  along  the  software  life  cycle  and  not  only  at 
the  coding  stage  :  a  full  set  of  Integrated  tools  is  needed.  That  is  why  the  DEI  is  currently  developing  an 
enhanced  version  of  ENTREPRISE  which  is  ailtllingual  (Ada,  LTR3 ,  ...),  and  Includes  the  following  tools  : 

-  DLAO(6)  for  software  requirements  specification, 

-  CLOVIS  for  software  design, 

-  IDAS  (7)  for  software  testing, 

*  configuration  management  tool, 

-  project  management  tool. 

Additional  tools  such  as  a  documentation  tool  will  be  Integrated  later  on. 

A  particular  implementation  of  ENTREPRISE  will  be  dedicated  to  aerospace  applications  :  the  SDA 
(8)  software  engineering  environment  which  is  developed  by  the  ITI  (9)  Consortium  under  the  auspices  of  the 
DGA- 


We  believe  that,  to  Improve  software  quality  and  especially  software  reliability,  the  effort  has 
to  be  put  on  the  software  requirements  specification  and  the  software  testing  phases.  This  is  consistent 
with  the  fact  that  these  phases  are  the  more  time  and  money  consuming.  Therefore,  we  will  focus  on  the  re¬ 
lated  tools  :  DLAO  and  IDAS. 

IDAS  is  already  presented  i.i  the  course  of  this  conference. 

DLAO  is  based  on  a  semi-formal  representation-  A  requirements  specification  is  expressed  in  terms 
of  objects  (data,  processes,  events,  states,  .  ••)  and  relationships  between  objects*  These  objects  are 
stored  in  a  data-base.  Taking  advantage  of  this  representation,  DLAO  provide  efficient  controls  of  the 
consistency  and  the  completeness  of  the  specification  ;  it  also  keeps  an  always  up-dated  version  of  this 
specification.  Finally  documents  written  in  a  subset  of  the  french  language  are  produced  :  easily  readable, 
they  are  used  as  a  contractual  basis  between  the  client  and  the  software  developer. 

It  has  to  be  emphasized  that  quality  at  the  specification  stage  is  essential  for  the  quality  of 
the  end-product  that  is  its  suitability  to  the  users 'needs. 

CONCLUSION 

The  above  description  of  the  CMF  AIR  protective  mechanisms  shows  that  special  attention  has  been 
paid  in  the  design  to  operational  dependability* 

The  advantages  of  such  a  choice  are  two  fold  : 

-  firstly,  the  operational  dependability  of  the  equipment  is  obviously  Improved.  More  specifically 
all  the  cest  mechanisms  described  above  ensure  high  Independence  of  software  functions*  Thus  in 
the  event  of  an  anomaly  concerning  a  non-crltical  function,  this  anomaly  has  no  effect  on  other 
functions,  thereby  enabling  the  mission  to  continue, 

-  secondly,  a  structure  of  this  type  reduces  the  cost  of  software  test,  since  the  independence  of 
functions  considerably  reduces  the  volume  of  regression  testing  which  has  to  be  performed 
following  any  modification. 

It  should  nevertheless  be  emphasized  that  these  advantages  are  achieved  at  the  cost  of  a  certain 
degree  of  performance  degradation.  Only  operational  use  of  the  CKF  AIR  computer  will  be  able  to  Justify  the 
compromises  made  between  operational  reliability  and  performance  considering  the  aimed  range  of  applica¬ 
tions. 


6  DLAO  :  Definition  de  Logiclel  Assistfte  )>ar  Ordinateur  (Computer  Aided  Software  Requirements 
Specification)  Is  a  trademark  of  Elect ronlque  Serge  Dassault 

7  IDAS  :  Informatisation  de  la  Detection  d'Anomaliea  dans  lea  SystSmes  (Systems  Anomalies  Detection 
Computerisation)  la  a  trademark  of  Elect ronlque  Serge  Dassault 

8  SDA  :  Systime  de  Developpeaent  Avlonlque  -  Avionics  Development  System 

9  ITI  ;  Integration  du  Traitement  de  l* Informat  ion  -  Data  Processing  Integration 
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SUMMARY 

This  paper  describes  the  techniques  used  by  Electronlque  Serge  Dassault  (ESD)  for  testing  embedded 
software,  including  in  particular  the  mission  computer  software  operated  in  the  MIRAGE  FI  and  MIRAGE  2000 
aircrafts. 

An  introduction  presents  the  main  characteristics  of  embedded  software  which  matte  testing  this 
software  an  activity  of  paramount  importance. 

A  few  figures  present  the  ESD  background  in  this  field.  Then  the  presentation  of  the  MI NERVE  (* ) 
methodology  used  at  ESD  for  developing  software  sets  the  scene  for  a  more  detailed  description  of  each 
testing  activity.  The  IDAS  (2)  and  SVR  (3)  tools  which  support  these  activities  are  dealt  with  in  the 
continuation  of  the  paper. 

Finally,  some  remarks  are  made  on  the  evolution  of  testing  techniques  and  a  conclusion  assesses 
the  current  situation  and  trends  in  software  testing  at  ESD. 

INTRODUCTION 

Avionic  applications  and  more  generally  embedded  applications  are  characterized  by  a  certain  num¬ 
ber  of  properties,  such  as  long  life-time  and  severe  volume  and  weight  constraints. 

A  certain  number  of  factors  specific  to  these  applications  have  a  particularly  important  influence 

on  test  activities.  First  of  all,  It  is  the  high  level  of  operational  dependability  required  which,  in- 

itself,  justifies  the  major  part  taken  by  test  (40  X  to  50  t)  In  the  development  process.  Next,  it  is  the 
"on-board"  aspect  which,  because  of  the  specificity  of  the  target  computers  and  their  input-output  systems, 
leads  to  host/target  development  and  imposes  operational  environment  simulation  for  tests  performed  on  the 
target  computers.  In  the  same  order  of  ideas,  it  is  the  "real-time"  aspect  which  means  that  the  software 
has  to  react  in  limited  time  to  external  events.  At  the  test  level,  this  "real-time”  characteristic  requi¬ 
res  the  software  environment  to  be  reproduced  as  faithfully  as  possible  and  the  execution  of  the  tested 

software  not  to  be  disturbed  (e.g.  by  instrumentation). 

Other  less  specific  factors,  such  as  the  high  modification  rate  and  the  concern  for  productivity, 
also  have  considerable  Influence  on  the  testing  of  avionic  software  (leading  respectively  to  regression 
testing  and  symbolic  testing). 

All  these  factors  make  the  testing  of  embedded  software  a  difficult  and  costly  operation  for  which 
few  tools  were  available  only  a  few  years  ago.  It  was  then  said  that  real-time  applications  constituted  the 
"lost  world"  of  software  test  and  debugging  (Robert  L.  GLASS,  Boeing  Aerospace  Company). 

This  paper  describes  the  solutions  which,  at  Electronlque  Serge  Dassault  (ESD),  are  being  and  have 
been  applied  to  these  problems  for  several  years. 

CHAPTER  1  :  EXPERIENCE  OF  ESD 

ESD  has  specialized  in  the  design,  development  and  manufacture  of  electronic  equipment  for  both 
civilian  and  military  applications. 

BSD  supplies  numerous  equipments  for  the  MIRAGE  FI  and  MIRAGE  2000  aircrafts  produced  by  Avions 
Marcel  Dassault-Breguet  Aviation  (AMD-BA)  for  which  it  has  developed  several  ranges  of  general-purpose  air¬ 
borne  computers  (the  Ml82  computers  for  the  MIRAGE  PI  aircraft  and  the  84  series  computers  for  the 
MIRAGE  2000  aircrafts).  Since  1977,  ESD  has  also  been  developing  the  operational  software  executed  on  these 
computers  as  well  as  the  associated  production  and  test  software.  In  order  to  meet  these  requirements,  the 
Company  has  established  large  software  engineering  teams  (more  than  200  people). 


1  MINERVE  :  MSthodologle  INdustrlelle  pour  l 'Etude,  la  Realisation  et  la  Validation  de  loglciel 

d'Equipement  (Industrial  Methodology  for  the  Study,  Production  and  Validation  of  Equipment 
Software),  is  a  trademark  of  Electronlque  Serge  Dassault 

2  IDAS  :  Informatisation  de  la  Detection  d* Anomalies  dans  les  Systfcmes  (System  Anomaly  Detection 

Computerization)  is  a  trademark  of  Electronlque  Serge  Dassault 

3  SVR  :  Software  Validation  Rack 
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More  than  20  million  bytes  of  operational  software  have  thus  been  delivered  for  a  total  of  15 
projects.  A  delivery  Is  made  for  each  project  approximately  once  a  month,  comprising  on  an  average 
600,000  bytes  of  code,  60,000  pages  of  listings  and  10,000  pages  of  documents. 

90  X  of  this  software  Is  written  In  LTR,  a  real-time  Pascal-like  language.  The  remaining  10  X  of 
this  software  corresponds  to  sections  for  which  program  execution  time  is  critical  and  which  are  therefore 
written  in  assembly  language.  Since  1987,  ESD  Is  also  equipped  with  tools  (compilers  and  testing  tools)  for 
applications  written  in  Ada  [HUE  87]. 

Emphasis  should  be  placed  on  the  major  effort  undertaken  by  ESD  over  the  last  ten  years  In  the 
area  of  software  engineering,  which  has  resulted  In  the  definition  and  implementation  of  MI NERVE 
methodology  and  la  the  development  of  tools  :  DLA0  (**),  IDAS  and  SVR.  The  next  chapter  briefly  describes 
the  MINERVE  methodology. 


CHAPTER  2  :  MINERVE  METHODOLOGY 

The  objective  of  MINERVE  Is  to  facilitate  the  production  of  high-quality  software  under  controlla¬ 
ble  conditions  of  cost  and  lead  time. 

The  quality  of  software  is  not  only  determined  by  its  conformity  to  requirements  but  also  by  Its 
ease  of  modification,  clarity,  accuracy  of  its  documentation,  operational  dependability,  performance 
characteristics,  etc. 

Cost  and  lead-time  control  depends  on  the  possibility  of  undertaking  at  all  times  action  contribu¬ 
ting  to  the  execution  of  contractual  obligations.  Such  control  Is  achieved  by  permanent  knowledge  of  pro¬ 
ject  progress  and  work  outstanding. 

In  order  to  achieve  the  above  objectives,  MINERVE,  a  key  element  for  software  quality  assurance  and 
control  within  ESD,  Is  based  on  the  following  three  principles  : 

-  projects  are  divided  Lnto  phases  and  stages  marked  by  clearly  defined  activities,  products  and 
responsibilities , 

-  the  quality  of  products  as  well  as  their  costs  and  lead  times  are  monitored  in  a  continuous 
manner, 

-  modifications  may  be  Included  whatever  of  the  degree  of  progress  in  accordance  with  a  single 
procedure  intended  to  avoid  any  degradation  of  software  quality. 

2.1  PRINCIPLE  OF  PROJECT  BREAKDOWN 

Projects  are  broken  down  chronologically  into  two  levels  (phases  and  stages)  in  accordance  with 
the  following  scheme  : 

PHASE  1  -  DEFINITION 

Stage  l.l  :  Overall  Definition  of  the  System 
Stage  1.2  :  Operational  Definition  of  the  Software 
Stage  1.3  :  Functional  Definition  of  the  Software 

PHASE  2  -  PLANNING 

Stage  2.1  :  Checking  of  Technical  Feasibility 

Stage  2.2  :  Definition  of  Technical  Means 

Stage  2.3  :  Reexamination  of  the  Software  Quality  Plan 

Stage  2.4  :  Reexamination  of  Planning  and  Costs 

PHASE  3  -  PRODUCTION 

Stage  3.1  :  Basic  Design 

Stage  3.2  :  Detailed  Design 

Stage  3.3  :  Coding  and  Unit  Tests 

Stage  3.4  :  Integration  Tests 

Stage  3.5  :  Functional  Tests 

Stage  3.6  :  Software  Validation 

PHASE  4  -  OPERATION 

Stage  4.1  :  System  Integration 

Stage  4.2  :  Software  Maintenance 

Stages  l.l  and  1.2  and  Phase  4  are  the  responsibility  of  the  weapon  system  contractor,  while  all 
other  stages  are  the  responsibility  of  the  software  producer. 


:  Diflnltlon  de  Loglclel  Asslst&e  par  Ordlnateur  (Computer-Aided  Software  Specification),  Is  a 
trademark  of  Electronlque  Serge  Dassault 
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A  STAGE  is  characterized  by  the  nature  of  its  MAIN  ACTIVITY .  The  latter  always  results  in  one  or 
■ore  formal  products  or  MINERVE  PRODOCTS  :  documents,  files,  magnetic  tapes,  etc.  Once  a  main  activity  has 
been  completed,  its  products  can  be  modified  only  by  a  special  procedure  (see  par.  2.3). 

2.2  PRINCIPLE  OF  CHECKING 

Checks  are  made  throughout  the  project  at  the  following  two  levels  : 

-  quality  of  products  (programs  and  documents), 

-  cost  and  lead  time. 

2.2.1  Quality  Control 

Any  quality  control  is  performed  at  the  level  of  a  MINERVE  product. 

These  controls  are  of  the  following  three  types  : 

-  Type  A  Control 

This  type  of  control  consists  of  performing  internal  checks  on  the  product  of  a  stage.  These 
checks  verify  that  this  product  obeys  the  specific  rules  (defined  in  the  software  quality  plan)  and  res¬ 
pects  the  general  standards  (defined  in  Che  software  quality  manual)  applicable  to  It. 

“  Type  B  Control 

This  type  of  control  consists  la  checking  the  coherence  between  the  products  of  a  stage  and  those 
of  former  stages.  This  type  of  control,  as  for  the  previous  type,  takes  the  form  of  rereading  documents  and 
project  reviews. 

-  Type  C  Control 

This  type  of  control  consists  of  program  testing  which  is  performed  in  four  successive  stages.  The 
tests  performed  during  the  stages  of  coding  and  unit  tests  (3.3),  Integration  tests  (3.4),  functional  teats 
(3.3)  and  software  validation  tests  (3.6)  check  the  conformity  of  the  programs  with  their  successive 
descriptions  established  in  the  course  of  the  'symmetrical'  stages  in  the  life  cycle  (cf.  figure  l)  : 
detailed  design  (3.2),  basic  design  (3.1),  functional  definition  (1.3)  and  operational  definition  (1.2). 

These  types  of  controls  are  illustrated  by  Figure  l. 


Figure  1.  SOFTWARE  LIFE -CYCLE  AND  QUALITY  CONTROLS 


2.2.2  Cost  sad  Lead-Time  Control 


This  control  Is  applied  at  close  Intervals  throughout  the  period  of  the  project.  It  consists  In 
evaluating  the  degree  of  work  progress  In  teres  of  cost  and  time  and  then  coopering  It  against  forecast  In¬ 
formation  recorded  in  a  reference  document. 

2.3  PRINCIPLE  OF  MODIFICATION 

Any  modification  can  be  accepted  Irrespective  of  the  degree  of  project  progress. 

No  MINERVE  oroduct  can  be  modified  outside  of  the  procedure  described  below  and  which  is  essential 
for  maintaining  coherence  between  the  various  products  throughout  the  life  cycle  of  the  software. 

-  Acquisition  of  a  Modi f lest Ion 

After  determining  the  HINERVB  product  ot  be  modified  located  the  furthest  upstream  in  the  software 
development  process ,  a  MODIFICATION  SHEET  for  this  product  Is  completed  by  the  customer  If  it  relates  to 
products  of  stage  1.2  or  by  the  software  supplier  If  It  relates  to  products  of  a  later  stage. 

-  Execution  of  a  Modification 

The  modification  applied  In  this  manner  reeults  In  rework  of  all  the  stages  whose  products  are  In¬ 
volved,  starting  with  that  furthest  upstream. 

The  application  of  modifications  Induced  In  the  various  products  concerned  is  recorded  on  a 
SUPERVISION  SHEET  raised  as  soon  as  the  decision  to  execute  has  been  taken. 


CHAPTER  3  :  SOFTWARE  TEST 

As  described  in  the  previous  Chapter,  software  testing  occurs  during  stages  3.3  to  3.6  of  the  life 
cycle.  The  present  Chapter  relates  only  to  actual  software  test,  excluding  program  inspections,  walk¬ 
throughs  and  reviews  [MYE  78]  which  are  performed  during  design  and  coding  stages. 

For  stages  1.2  to  3.2,  the  system  has  been  divided  into  different  levels  (operational  functions, 
software  functions,  modules,  parts,  etc). 

At  each  stage,  the  tests  therefore  apply  to  the  breakdown  level  described  In  the  "symmetrical" 
stage  (see  Figure  l)  In  accordance  with  a  process  of  progressive  recomposition  of  software  "blocks"  of 
Increasing  size.  This  approach  has  the  advantage  of  facilitating  environmental  simulation  at  all  stages. 

When  larger  assemblies  of  software  are  tested,  the  combinatory  explosion  leads  to  abandon  testing 
information  Internal  to  programs,  giving  way  to  functional  tests  which  become  more  significant.  The  corres¬ 
ponding  test  techniques  are  commonly  identified  by  the  terms  "white  box"  test  and  "black  box"  test. 

Use  of  white  box  and  black  box  tests  is  summarized  in  figure  2  : 


STAGE 

WHITE  BOX  TEST 

BLACK  BOX  TEST 

1 

Unit  tests 

Branch  tests 

Path  tests 

External  part  tests 

1 

Static  Integration  tests 

Branch  tests 

Inter-part  Interface  tests 

External  module  tests 

1 

Dynamic  integration  tests 

Inter-process  Interface  and 
synchronization  tests 

B 

Functional  tests 

External  software 
function  tests 

B 

Validation 

External  operational 
function  tests 

Figure  2.  TESTING  IKTHODS 

It  should  be  emphasized  that  test  activity  (Identifying  a  malfunction)  Is  associated  with  a 
debugging  activity  (localizing  the  error(s)  which  cauae(s)  the  malfunction).  Debugging  necessitates  the 
exploitation  of  information  internal  to  the  program  (approach  of  the  "white  box"  type). 

A  more  detailed  description  of  the  test  techniques  used  in  stages  3.3  to  3.6  Is  given  in  the  fol¬ 
lowing  paragraphs. 
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3.1  unit  tests 

The  breakdown  level  concerned  is  che  “part*',  whose  character  let  Ice  are  its  mail  else  (less  chan 
100  inet ructions),  to  correspond  to  a  progressing  language  structure  possessing  a  single  entry  point  and  a 
single  exit  point  (e.g.  a  procedure)  and  to  be  a  compilation  end  archiving  unit. 

Unit  test*  generally  Include  a  pattern  of  entry  data  and  a  pattern  of  expected  output  data.  In 
this  regard  they  say  be  viewed  as  using  a  'black-box'  approach  (external  part  teats).  But  they  also 
consider  internal  characteristics  of  the  'part'  such  ss  'branches'  and  'nodes'  (see  below)  end  therefore 
belong  equally  to  the  'white-box'  class  of  tests- 

Unit  testa  have  to  ensure  a  maximum  reliability 

-  the  entry  data  pattern  must  lead  to  the  execution  of  each  'branch*  of  the  part.  A  'branch*  Is  a 
sequence  of  statements  between  two  'nodes'  (If,  case,  ...  statements).  The  entry  data  pattern 
must  also  validate  to  a  large  extent  that  there  Is  no  correlation  between  the  nodes  (l.e.  that  a 
node  In  a  given  stato  (exit  branch)  does  not  'freeze*  the  state  of  another  node).  This  lead  to 
test  a  set  of  paths  which  number  is  expressed  by  the  'cyclomatlc  number'  [MCA  76]  It  should  be 
noted  that  an  execution  of  all  possible  paths  la  generally  too  costly  while  not  Improving 
significantly  the  level  of  coverage, 

-  unit  tests  executions  muse  be  Independent  :  entry  date  patterns  Mist  not  be  generated  by  pre¬ 
vious  executions  of  the  same  test. 

-  software  robustness  must  be  checked.  This  means  that  entry  data  patterns  have  to  include  values 
covering  the  normal  range  of  parameters  but  also  values  outside  this  range.  It  must  be  aleo 
controlled  that  no  'side-effect'  Is  Induced  :  che  teeter  has  to  verify  chat  the  'environment'  of 
the  part  (such  as  entry  data)  is  not  altered  by  the  execution  of  the  test, 

-  unit  test  must  check  that  execution  time  and  memory  space  constraints  (as  expressed  In  the 
SOFTWARE  DETAILED  DESIGN  DOCUMENT)  are  satisfied. 

Unit  teats  have  to  be  maintainable 

-  functional  test  description,  test  operations  and  test  results  have  to  be  archived  In  UNIT  TEST 
FILES,  MI NERVE  product  of  the  unit  tests  stage.  A  modification  of  a  part  will  generally  cause  an 
update  of  the  corresponding  UNIT  TEST  FILE,  so  that  the  test  case  remain  consistent  with  the 
code. 

-  UNIT  TEST  FILES  will  be  used  to  perform  regression  testing  l.e.  reexecuting  a  set  of  unit  tests 
whenever  a  part  Is  modified  (see  IDAS  tool,  chapter  4.1). 

3.2  INTEGRATION  TESTS 

The  breakdown  level  concerned  may  be  a  process  or  module. 

A  process  corresponds  to  the  set  of  programs  whose  execution  Is  subject  to  the  same  activation 
condition  (external  or  internal  event,  frequency). 

A  module  is  the  reusable  component  of  software  beetween  different  versions  of  an  application  (e.g. 
for  a  combat  aircraft,  versions  related  to  different  missions  or  armaments). 

It  belongs  to  a  unique  process,  has  a  functional  consistency  and  is  composed  of  an  Interface  part 
and  a  body  part.  The  interface  expresses  the  visibility  from  and  towards  the  module,  while  the  body  part 
comprises  local  data  and  statements  (part  calls).  The  latest  programming  languages  (LTR3,  Ada)  now 
represent  process  and  module  structures  very  simply. 

Integration  tests  are  of  two  kinds  : 

-  STATIC  INTEGRATION  TESTS  :  they  consider  a  set  of  paths  Inside  s  process  or  a  module  and  check, 
with  respect  to  the  SOFTWARE  BASIC  DESIGN  document  (MINERVE  product  of  the  basic  design  stage)  : 

.  the  Interface  between  parts  and  modules  (l.e.  consistency  between  formal  and  actual 
parameters  In  parts  calls), 

.  the  functional  aspect  of  modules  (a  black-box  type  of  test). 

-  DYNAMIC  INTEGRATION  TESTS  :  they  check  the  Interfaces  between  processes  and  the  external  envi¬ 
ronment,  and  between  the  processea  themselves.  They  also  control  time  sharing  (cycle 
duration,  synchronization,  etc.)  and  data  management  (accesa  to  shared  variables,  etc.). 

As  for  unit  tests,  integration  tests  are  archived  In  INTEGRATION  TEST  FILES,  MINERVE  product  of 
the  Integration  test  stage. 

3.3  FUNCTIONAL  TESTS 

The  purpose  of  this  stage  Is  to  check  the  conformity  of  a  'software  function',  against  the 
SOFTWARE  FUNCTIONAL  SPECIFICATION  document  (a  MINERVE  product  of  the  software  functional  definition  stage). 

A  'software  function*  Is  the  first  level  of  breakdown  of  the  overall  software.  It  may  be  related 
to  an  operational  point  of  view  (e.g.  Air-to-ground  function)  or  to  an  internal  point  of  view  (e.g.  Digital 
bus  management  function). 


Functional  tests  are  archived  la  FUNCTIONAL  TEST  FILES,  HI NERVE  product  of  the  Integration  teet 
stage.  They  include  : 

~  a  sequence  of  actions  described  In  functional  teres  and  as  a  sequence  of  Instructions  specifying 
how  to  operate  the  tools, 

“  a  set  of  checks  also  described  in  a  dual  point  of  view.  It  should  be  ooted  that  soee  of  the 
checks  are  performed  annually,  using  'images'  displayed  oa  the  screen  by  the  SVR  tool  (see 
chapter  4.2). 

The  following  three  types  of  test  are  executed  : 

“  nominal  tests,  corresponding  to  cases  of  normal  weapon  systea  operation, 

-  fault  tests,  corresponding  to  cases  defined  at  the  definition  stage, 

-  random  fault  testa  with  the  ala  of  evaluating  the  robustness  not  only  of  the  program  but  also  of 
the  functional  specifications,  thus  possibly  questioning  the  latter. 

3.4  SOFTWARE  VALIDATION 

The  tests  performed  for  validating  the  software  are  similar  to  the  functional  tests  but  apply  to 
the  overall  program  and  are  executed  with  respect  to  the  SOFTWARE  OPERATIONAL  SPECIFICATION  and  SOFTWARE 
INTERFACE  SPECIFICATION  documents  (KINERVE  products  of  the  software  operational  and  software  functional 
definition  stages).  At  thla  staga,  regression  teste  are  applied  systematically. 

Validation  tests  are  archived  In  the  VALIDATION  TEST  FILES,  MINERVE  product  of  the  stage.  They 
constitute  s  contractual  basis  for  software  acceptance  between  the  prime  contractor  end  the  software 
developer. 


CHAPTER  4  :  TOOLS 

The  tools  used  at  various  software  test  stages  are  figured  below  : 


3.3 

Unit  tests 

IDAS 

3.4 

Integration  tests 

IDAS 

3.5 

Functional  tests 

IDAS  SVR 

3.4 

Software  validation 

IDAS  SVR 

For  unit  U.sts  and  integration  tests,  s  static  version  of  IOAS  Is  used.  It  is  a  test  harness  that 
provides  the  ability  to  express  the  data  entry  pattern  and  the  test  actions  In  terms  of  a  test  program 
using  s  dedicated  language.  But  at  this  stage  real-time  aspects  are  either  ignored  (unit  tests  and  static 
Integration  tests)  or  only  simulated  (dynamic  Integration  tests).  The  teat  programs  and  the  tested  programs 
are  run  both  on  the  host  computer. 

For  functional  tests  and  validation  tests,  a  dynamic  version  of  IDAS  Is  used  (cf.  fig.  3).  This 
version  runs  on  a  dedicated  machine  separated  from  the  target  machine.  It  provides  the  essential  capability 
of  observing  the  dynamic  behaviour  of  the  tested  program  without  any  disturbance.  But  It  does  not  provide 
the  dynamic  simulation  of  the  environment.  This  Is  performed  by  the  Software  Validation  Rack  (SVR). 

4.1  IDAS 

IDAS  (HUE  851  1*  *  software  test  system  specially  designed  for  real-time  applications.  The  mode  of 
operation  consists  In  executing  the  tested  program,  observing  Its  behaviour  and  checking  It  with  respect  to 
a  reference  behaviour  JAVA  79).  IDAS  can  adapt  to  a  large  range  of  programming  languages  (LTR,  Ada,  etc.) 
as  well  as  various  target  computers  on  which  the  tested  program  Is  executed. 

IDAS  is  based  essentially  on  the  use  of  s  test  language  allowing  to  write  teat  programs  which  may 
be  stored  and  reexecuted  (regression  testing). 

Test  programs  allow  handling  at  the  symbolic  level  of  the  variables  and  Instructions  of  the  tested 
program.  For  this  purpose,  IDAS  Is  connected  to  the  coding  tools  (compilers,  assemblers,  etc.)  vis  a  post¬ 
processor  which  generates  a  data  base  of  tested  objects  descriptors. 

The  static  version  of  the  IDAS  system  uses  s  target  computer  simulator  Instead  of  the  actual  em¬ 
bedded  computer. 
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Th«  dyntalc  version  of  IDAS  comprises  distinct  teat  and  target  machines  Interconnected  by  a  hard¬ 
ware  Interface  which  enables  to  observe  the  real-time  behaviour  of  the  tested  program  without  any 
disturbance*  Xt  is  possible  to  trace  : 

-  simple  events  occurring  during  execution  of  the  program  under  test  (execution  of  en  Instruction, 
handling  of  a  variable), 

-  complex  elements  obtained  by  the  logical  and/or  temporal  combination  of  simple  events* 

The  general  structure  of  the  dynamic  version  of  IDAS  la  Illustrated  by  Figure  3. 

The  "core"  of  the  IDAS  system  consists  of  i 

-  an  Interpreter  used  for  debugging  the  test  programs, 

-  s  compiler  used  for  executing  the  test  programs  In  raal-tlma, 

-  s  debugging  tool  used  for  fixing  errors  in  Che  tested  program. 

This  core  Is  common  to  ell  configurations  of  IDAS,  whatever  programming  language  or  target  machine 
ts  used.  It  constitutes  a  hosting  structure  for  additional  tools.  Such  tools  have  already  been  produced, 
such  as  : 

-  a  modelltzatlon  tool  which  enables  to  express  s  behaviour  model,  using  the  Peeri  nets  formalism 
(LAM  85], 

-  a  simulation  tool  which  enablea  to  substitute  'templates'  to  Instructions  or  procedures. 
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4.2  SOFTWARE  VALIDATION  BACK  (SVR) 


The  SVR  Is  an  assembly  of  hardware  and  software  used  for  dynamic  testing  of  real-time  software. 

The  functions  performed  by  the  SVt  consist  In  simulating  the  environment  of  the  target  computer, 
and  checking  the  behaviour  of  the  embedded  software  through  the  operational  links. 

The  simulation  takes  Into  account  an  aircraft  flight  path,  parameters  of  which  are  calculated  and 
recorded  In  a  computing  centre*  The  use  of  a  graphics  console  allows  simulation  of  control  unit  front 
panels  and  operational  displays.  In  particular.  It  allows  the  simulation  of  operational  actions  (e.g.  ac¬ 
tions  on  the  control  panels)  and  environment  modification  (e.g.  failure  of  an  equipment).  This  console  also 
displays  the  Information  carried  over  the  operational  links. 

The  tests  are  executed  either  manually  or  automatically.  In  the  former  case,  the  simulation  of 
operational  Actions  and  environment  modification  la  performed  by  the  operator.  In  the  latter  case,  the 
simulation  is  derived  from  a  test  executed  previously,  known  as  a  "reference  test".  During  this  test  the 
list  of  parameters  to  be  checked  and  the  reference  values  are  recorded.  This  information  may  be  manually 
modified  In  the  course  of  test  execution  to  take  Into  account  the  Impact  of  the  software  modification  on 
the  scenarios. 

The  hardware  structure  of  the  SVR  Is  Illustrated*  by  Figure  4. 


Figure  4.  SOFTWARE  VALIDATION  RACK  ARCHITECTURE 


The  SVR  hardware  consists  of  two  main  assemblies  : 

-  an  operating  and  simulation  system  connected  to  : 

•  the  operating  link  for  the  target  computer  (computer  atop/restart), 

.  standard  peripherals  :  printer  used  for  editing  anomalies,  disc  on  which  data  required  by  the 
automatic  tests  (flight  parameters,  reference  parameters,  test  results)  are  stored  and  a  video 
screen/keyboard  for  system  operation. 

-  an  interface  management  system  connected  to  : 

.  the  target  computer(s)  via  operational  links 

.  a  graphics  screen  with  mouse  and  light-pen,  used  to  display  images  of  operational  Interfaces 
(control  panels,  head-up,  head-down,  ...) 
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The  SV1  software  consists  of  the  following  four  wain  assemblies  : 

-  flight  parameter  generation  software  : 

It  generates  flight  parameters  transmitted  to  the  SV1  In  a  form  compatible  with  the  operational 
digital  links. 

This  software  la  run  on  equipment  distinct  from  the  SVK  (IIM  computing  canter). 

-  SVR  operating  software  : 

It  presents  a  dialoguing  Interface  in  the  form  of  programmable  function  keys  implementing 
arborescent  menus.  This  software  Includes  : 

•  static  debugging  of  the  target  computer  software, 

.  validation/acceptance  test  with  environment  simulation.  Including  selection  of  various  opera¬ 
ting  modes  (normal,  slow  motion,  step  by  step  at  the  cycle  level)  and  the  selection  of 
diaplaya  and  presentations  (room,  ...). 

This  software  Is  executed  cm  the  operating  and  simulation  system. 

-  environment  simulation  software  : 

It  ensures  the  simulation  of  each  equipment  transmitting  data  to  the  target  computer(s).  This 
simulation  is  limited  to  the  functions  generating  these  date. 

This  software  is  executed  by  the  operating  end  simulation  system. 

-  automatic  teat  software  : 

It  has  the  following  two  purpoaaa  : 

.  to  allow  recreation  of  tast  configuration#,  which  Is  useful  for  analysing  malfunction  during 
functional  tsst  and  validation, 

•  to  automate  test  operation  and  rasulta  analysis*  This  function  Is  extensively  used  for  accep¬ 
tance  procedures. 

This  software  la  executed  on  the  operating  and  simulation  syatem. 


CHAPTO  S  t  TURDS  IR  SOFTWARE  TESTING 

Short  and  medium-term  evolution  of  software  tests  do  not  relate  as  much  to  actual  test  methods  and 
tools  as  to  Integration  of  the  test  process  with  other  activities  of  software  development. 

The  present  Chapter  Is  therefore  mainly  concerned  with  the  effect  due  to  the  appearance  of  tools 
used  earlier  In  the  software  life  cycle  (mainly  software  specification  aid  tools)  and  to  the  present 
tendency  of  Integrating  tools  within  Software  Engineering  environments. 

5.1  TEST  ARD  SPECIFICATIOR  METHODS 

Awareness  of  the  exponentially  Increasing  cost  of  modifications  during  the  course  of  development 
has  prompted  over  the  last  few  years  considerable  work  in  the  ares  of  software  definition  (and  to  a  lesser 
degree  software  design). 

At  BSD,  thla  effort  has  resulted  in  the  production  of  the  DLAO  tool  allowing  software  requirements 
specifications  to  be  expressed  in  a  semlformal  manner.  The  basic  concepts  made  available  to  the  user  are  : 

-  Informat lorn  representing  the  operational  data  (e.g.  mode  of  radar  operation), 

-  Interfaces,  the  physical  support  of  data  (e.g.  encoding  used  for  transmitting  over  a  multiplexed 
bus) , 

-  events  which  modify  the  set  of  activated  processes  (e.g.  change  of  mode  of  radar  operation), 

-  atataa  which  characterise  software  operation  at  a  given  Instant  (e.g.  air-to-ground  mode), 

-  processes  corresponding  to  elementary  tasks  (e.g.  ballistic  calculations). 

The  date  defined  In  this  manner  by  the  user  as  well  ae  the  associated  comments  are  stored  In  a  da¬ 
ta  baas  which  thus  always  contains  an  updated  representation  of  the  software  requirements  specif lest  Ions. 
Many  possibilities  of  producing  s  document  are  offered,  exploiting  the  possibilities  of  data  base  queries. 

Such  specification  formalisation  should  allow  In  the  fairly  nea.-  future  significant  progress  In 
tast  automation.  ESD  Is  conducting  work  In  this  direction,  aimed  at  the  automation  of  tast  acenarloa 
generation.  The  approach  adopted  consists  in  generating  s  prototype  from  s  subassembly  of  the  requirements 
specification  (defined  by  the  user)  and  than,  by  means  of  Input  stimuli,  tn  producing  output  data  by  exer¬ 
cising  this  prototype. 

The  input  stimuli,  which  constitute  the  scenario  input  data,  can  be  generated  manually  or  seml- 
autometlcally  from  the  requirements  specification.  In  the  latter  case,  the  user  has  the  possibility  of 
limiting  the  Information  Involved  in  the  scenario#  In  order  to  avoid  the  phenomenon  of  combinatory 
explosion.  The  output  data  generated  by  the  prototype  constitute  the  reference  value  used  when  executing 
the  teat  scenarios. 
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5.2  TOOL  INTEGRATION 

Th«  dm  warentia  of  Software  Engineering  concepts  1*  loading  to  Increasingly  higher  integration 
of  tools.  A  significant  euaple  is  the  work  presently  undertaken  by  the  IT1  (5 )  Consortium  of  eight  Trench 
companies  of  the  aerospace  sector.  This  work  aims  at  producing  software  environments  dedicated  to  avionic 
ays tens  and  on-board  software  development. 

Such  envlronnents  are  providing  powerful  nechanlsne  allowing  the  integration  of  tools,  such  as  : 

-  a  software  raqulremanta  specification  tool, 

-  a  design  tool, 

-  coding  tools, 

-  testing  tools. 

These  nechanlsne  consists  essentially  of  : 

-  an  "object**  data  base,  standard  neana  of  communication  between  tools, 

-  a  configuration  nenagensnt  system  ensuring  permanent  coherence  between  the  objects  of  the  base 
(requirements  specifications,  design  documents,  code,  test  programs). 

Better  Integration  between  the  test  tools  themselves  (SVR  and  IDAS)  will  also  be  ensured  thereby 
asking  It  possible  from  the  sane  work  station  to  control  simultaneously  the  operations  of  functional  and 
validation  test  performed  by  the  SVR  and  debugging  operations  (in  particular,  the  ellalnatlon  of  faults  re¬ 
lated  to  real-time  problems)  performed  by  IDAS. 


CHAPTER  6  :  CONCLUSION 

Our  experience  of  avionic  software  testing  allows  us  to  present  a  largely  positive  situation. 

The  neln  objective,  l.e.  software  quality,  has  been  achieved  :  less  than  one  error  per  year  and 
per  progran  has  been  found  In  flight. 

We  are  also  nelntalnlng  control  of  our  costs  and  lead  tines  In  spite  of  the  high  rate  of  evolution 
of  our  software. 

We  have  also  noted  continuous  growth  of  our  productivity,  which  has  Increased  by  a  factor  of  near¬ 
ly  five  between  1979  and  1987.  This  should  be  weighted  by  Increased  use  of  computer  resources  at  the  same 
time,  but  the  overall  balance  Is  positive. 

Our  efforts  today  are  tending  to  maintain  this  growth  In  productivity  and  we  hope  to  achieve  this 
objective  In  the  following  two  main  ways  : 

-  continuous  effort  at  the  u ait  test  and  Integration  test  level  slace,  as  emphasized  in  Chapter  3, 
the  earlier  errors  are  detected  In  the  life  cycle,  the  less  they  cost  to  correct.  In  particular, 
we  Intend  to  perfect  the  methods  and  tools  allowing  us  better  control  over  the  coverage  factors 
of  these  tests, 

-  larger-scale  Integration  of  our  development  tools  within  software  engineering  environments 
(Including  the  use  of  multi-window  graphics  work  stations)  and  their  continuous  adaptation  to 
avionic  system  design  methods. 
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SUMMARY 

The  increased  use  of  advanced  electronics  has  given  nod era  combat  aircraft  phenomenal  levels  of 
performance,  but  at  a  stiff  price  in  Initial  cost,  maintenance  workload  and  aircraft  availability. 
Hence,  aircraft  design  la  shifting  to  give  equal  emphasis  on  performance,  affordability, 
maintainability,  and  reliability  In  the  development  of  avionic  systems.  This  paper  discusses  the 
challenges  and  beneflta  of  an  avionics  architecture  concept  which  integrates  avionic  functions  at  the 
system  level  thereby  Improving  the  system's  sccuracy,  increasing  its  Immunity  to  failure,  and 
decrsaslog  Its  rsllsnce  on  multiple  redundant  sensors.  This  dtalgn  philosophy,  which  permits 
resources  to  be  shared  across  subsystems,  requires  a  highly  coupled  system-wide  management  and  control 
program  (operating  system)  supported  by  a  wide- band  data  distribution  network,  high-speed  data  and 
signal  processors,  and  extensive  mass  memory.  The  implementation  strategy  for  this  avionics 
architecture  la  the  system-wide  utilisation  of  common  modular  building  blocks  using  advanced 
microelectronics  such  as  VHSIC,  standard  3/4  ATR  modules  and  integrated  recks,  and  interconnected  by 
fiber  optic  networks. 

The  generic  integration  approach  and  architecture  produced  by  the  PAVE  PILLAR  program  is  the 
foundation  for  avionics  development  in  next  generation  aircraft  for  the  U.S.  Department  of  Defense  and 
include  such  aircraft  as  the  USAF  Advanced  Tactical  Fighter  (ATF). 


IHTRODUCTION 


In  performing  its  role  of  research  and  development  Innovator  for  aviation  alectronica.  the  Avionics 
Laboratory,  an  active  member  of  the  Air  Force  Wright  Aeronautical  Laboratories,  has  initiated  a  major 
program  to  develop  the  concepts  for  the  next-generation  Integrated  avionics  system  architecture.  The 
program  la  called  PAVE  PILLAR  and  It a  purpose  is  to  achieve  significant  Improvements  In  the 
availability,  coat  of  ownership  end  mission  effectiveness  of  future  combat  aircraft. 

Current  avionic  systems  ere  organized  by  functional  areas.  Typical  of  these  are  flight  control, 
stores  management,  electronic  warfare,  navigation,  weapon  delivery,  cossninicatlon,  electrical  power 
control,  engine  control,  dedicated  controls /display a,  etc.  The  systems  integration  which  exists  Is 
Halted  to  the  subsystem  or  intrafunctional  level.  This  subsystsm  approach  arose  partially  because  of 
the  lack  of  technology  to  support  a  total  system*  Integration  approach  and  partially  becauac  of 
traditional  political  boundaries. 

These  unique  eubeystems,  some  of  which  heve  been  developed  at  the  eleventh  hour  to  satisfy  an 
operational  deficiency,  put  a  tremendous  strain  on  the  logistics  support  structure  of  the  Air  Force. 
This  is  because  each  unique  subsystem  has  numerous  unique  line  replaceable  units  (LRUs),  all  of  which 
require  sparing,  which  results  in  an  extremely  high  life  cycle  cost  for  the  weapon  eystem. 

EARLY  INTEGRATION  APPROACH 


With  the  adoption  of  MIL-STD-1553B,  Aircraft  Internal  Time  Division  Command /Response  Multiplex  Data 
Bus,  soma  of  the  newer  U.S.  Air  Force  strategic  and  tactical  aircraft  have  begun  the  teak  of 
Integrating  beyond  the  eubeystem  level.  However,  even  theee  never  system  Integration  activities  have 
addressed  only  the  basic  avionics  functions  of  navigation,  weapon  delivery,  communication,  and  to  some 
extent,  controls  and  displays.  Analysis  of  s  currant  tactical  aircraft  shows  that  the  avionics  suite 
consists  of  approximately  55  line  replaceable  units  with  437  different  sub-assembly  spare  types.  The 
1553  date  bus  and  dedicated  cables  alone  require  254  harnesses  to  connect  the  external  line 
replaceable  unite.  The  combined  number  of  Internal  and  external  interconnects  explodes  to  more  than 
86,600  connections.  Forty  percent  of  the  maintenance  actions  on  the  flightline  are  concerned  with 
these  cables  and  connactora. 

Analysis  shows  that  by  applying  high  spaed  fiber  optic  multiplexing  end  Very  High  Speed  Integrated 
Circuits  (VHSIC)  technologies,  the  number  of  cables  and  connectors  can  be  reduced  by  ea  much  as 
thirty-five  percent.  However,  this  does  not  imply  that  one  can  just  Insert  theee  technologies  end 
receive  the  Improvements.  One  must  structure  or  partition  the  technologies  into  e  system  architecture 
which  will  permit  maintenance  personnel  to  easily  Isolate  faults  and  to  replace  felled  avionics 
components.  Also,  mission  analysis  has  shown  that  the  system  architecture  must  be  flexible  enough  to 
support  alr-to-efr  sod  air-to-ground  mission  raquiraments.  This  leads  ona  to  conclude  that  tha  system 
architecture  must  adapt  during  tha  llfe-tlma  of  the  eystem  to  constant  changes  and  new  mission 
rsqulrcmsnts. 

It  follows  then  that  the  hardware  and  software  which  form  tha  systsm  architecture  must  have  a  modular 
basis  which  will  permit  tha  maintenance  personnel  to  remove  and  replace  the  components,  yet  allow 
system  designers  to  adapt  the  avionics  suite  to  new  requirements.  PAVE  PILLAR  was  created  to  solve 
these  problems. 


EVOLimOWAIT  PROCESS 


The  PAVE  PILLAR  program  la  an  evolutionary  procaaa  whereby  an  avionics  architecture  la  developed  using 
revolutionary  new  technology.  The  trend  In  avionics  system  design  is  to  increase  system  integration 
thereby  Improving  system  accuracy,  increasing  system  immunity  to  failures,  and  decreasing  system 
reliance  on  multiple  redundant  sensors.  This  design  philosophy  which  permits  resources  to  be  shared 
across  subsystems  requires  a  highly  coupled  system  vide  management  and  control  program  (operating 
eyatem)  supported  by  a  wide  bend  deta  distribution  network,  high  speed  processor e,  and  extensive  mass 
memory.  The  ability  to  consldsr  Integration  of  this  magnitude  Is  dependent  on  recent  advances  In 
microelectronics  tschnology,  most  notably  the  advent  of  VBSIC  technology. 

The  PAVE  PILLAR  avionics  architecture  la  functionally  divided  Into  three  distinct  sress: 

Mission  management 

Sensor  management 

Vehicle  management 

The  three  areas  define  the  enclosing  boundaries  for  resource  sharing,  sparing,  and  substitution. 

Unique  characteristics  of  each  of  these  areas  preclude  the  utilisation  of  resources  across  areas  for 
the  purpose  of  function  recovery  or  reconfiguration.  This  dose  not  Imply  that  the  areas  do  not 
contain  many  cosskct  hardware  elements,  but  that  the  organisation,  connectivity,  and  control  of  these 
components  restrict  their  practical  use  In  functional  system-wide  reassignment.  Each  of  the  three 
areas  have  associated  with  them  a  logical  processor  type  end  varying  Interface  requirements.  Figure  1 
Illustrates  ths  top  level  organisation  of  the  PAVE  PILLAR  avionics  architecture,  system  elements  are 
built  from  a  set  of  cosmos  modules  supporting  prograamable  processing,  I/O,  and  memory  storage 
functlona.  The  Interfaces  between  system  elements  are  standard  high  speed  time  division  multiplex 
buses  and  data  links,  all  utilizing  fiber  optics  technology. 

MISSIOH  MAHACEMKKT  AREA 


The  Mission  Management  area  conalste  of  Mission  Data  Processors,  Mission  Avionics  Multiplex  Bus,  Block 
Transfer  Multiplex  Bus,  System  Mass  Memory,  Stores  Management  System,  end  e  collection  of  Interfaces 
to  the  Mission  Avionics  Bus.  This  ares  provldss  the  resources  to  perform  the  mlsalon  and  system 
management  functions  such  as  fire  control,  target  acquisition,  navigation  management,  defense 
management,  stores  management,  T7/TA/0A  functions,  and  crew  station  management.  The  Mission 
Management  Area  contains  Identically  configured  Mission  Data  Processors  all  connscted  to  the  Mission 
Avionics  Multlplsx  Bus  and  loadabla  from  the  System  Mass  Memory  vis  the  Block  Transfer  Multiplex  Bus. 
All  Mission  Processing  control  and  data  axchanga  outside  of  loading  operations  is  performed  using  tbs 
Mission  Avionics  Multiplex  Bus.  Ths  Mission  Management  Area  controls  Job  assignments  for  the  Signal 
Processors  and  datermlnea  the  connection  paths  from  Signal  Procaaaora  to  sensor  front  ends.  High 
level  processed  Information  Is  collected  from  the  Signal  Processors  (such  as  target  tracks,  CHI 
reception  results,  threat  descriptions)  and  modlng  and  control  data  la  provldsd  back  to  both  the 
Signal  Processors  and  the  sensor  front  ends. 

Ths  Mission  Management  Area  also  Interfaces  with  the  Vehicle  Management  Area  to  receive  navigation 
state  information  and  to  supply  route  end  trajectory  commands.  Other  Interfaces  ere  to  cockpit 
multi-function  switches,  Storss  Management  System,  end  miscellaneous  avionics  control  devices  not 
directly  Interfaced  to  the  Mission  Avionics  Bus  fhelmst  mounted  sight,  voice  recognition  syatem,  deta 
recorders /readers) .  Ths  Mission  Management  Ares  collects  the  health  end  statue  of  ell  core  elements 
and  sensor /subsystem  components  for  maintenance  history  end  to  maintain  mission  functional  capability. 

SEHSOR  MAMACEHEHT  AREA 


The  Sensor  Management  area  conalste  of  a  set  of  common  Signal  Processors,  s  sensor  data  distribution 
network,  a  sensor  control  nstwork,  a  data  exchange  network,  and  a  video  distribution  system.  The 
sensor  management  area  provides  the  signal  processing  functions  and  Interfaces  necessary  to  convert 
conditioned  data  from  multiple  sensors  via  a  sensor  network  Into  processed  Information  suitable  for 
distribution  to  other  avionics  systems.  The  sensoT  management  area  accapta  encrypted  data  from  a 
TRAMS EC /COMSEC  controller(s)  and  processes  the  data  for  transmission.  This  area  also  distributes 
processed  digital  video  to  crew  displays  and  distributes  sensor  control  commands  to  sensors  via  a 
sensor  control  network.  Signal  Processor  task  assignment,  sensor  data  distribution  network  control, 
and  Signal  Processor  resource  reconfiguration  Is  managed  by  the  Mission  Data  Processors. 

VEHICLE  MAMAGEMEMT  AREA 


The  Vehicle  Management  System  (VMS)  la  an  independent  subsystem  supporting  the  fundamental  flight  and 
airframe  related  control  functions.  The  VMS  Management  area  la  physically  Isolated  from  the  rest  of 
the  architecture  for  eefety  of  flight  reasons  and  contains  a  higher  degree  of  phyelcal  redundancy, 
usable  only  within  the  VMS  area.  The  VMS  management  area  contains  ?MS  Data  Processors, 

Controls /Displays  interfaces.  Plight  Sensor /Actuator  Interfaces,  Electrical  Power  Control 
Interfaces,  Engine  Control  Intarfacaa,  and  Utility  Systems  Interfaces.  The  VMS  Data  Processor  is 
essentially  identical  to  the  Mission  Data  Processor  except  for  memory  configuration,  multiplex  bus 
interfaces,  and  reconfiguration  methods.  The  VMS  Data  Processor  has  Read  Only  Memory  for  ell  program 
storage  and  does  not  perform  any  program  loading.  The  VMS  Data  Processor  also  haa  six  High  Spmad  Bus 
Intarfacaa.  Two  dual  redundant  interfaces  to  the  Mission  Avionics  Multiplex  Bus  and  four 
simultaneously  active  bus  Intsrfaces  to  the  VMS  Multiplex  Bus.  Each  VMS  Date  Processor  contains  the 
entire  program  load  to  perform  all  VMS  functlona.  Reconfiguration  la  accomplished  by  activating 
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doTunt  tukj  In  available  spare  VMS  Data  Processor  resources.  The  flight  essential  nature  of  VMS 
proceaalng  necessitates  a  very  high  degree  of  functions!  reliability  (Vall-Op/Fall-Op/Pail-Sane) . 
This  la  accomplished  by  physical  quad  redundancy  of  sensors,  buses,  processors,  and  actuators  In  the 
VMS  processing  area.  The  partitioning  of  processing  functions  among  VMS  Data  Processors  Tetalns  the 
quad  redundant,  simultaneously  active  characteristic  of  the  VMS  area. 

SYSTEM  CONTROL 


Control  of  the  cote  proceaalng  ayatem  la  provided  by  a  distributed  software  architecture  providing  for 
commonality  of  control  softvart  across  the  mission  processors,  flight  control  processors,  and  signal 
processors.  Major  control  functions  include: 

-  Initialisation  and  system  startup  and  restart 

-  Assignment  of  application  software  task  to  proceaalng  resources  (software  configuration  and 
reconfiguration  computing  resources  management) 

-  Sequencing  and  synchronization  of  related  software  tasks 

-  Management  of  aeneor  and  other  device  resources  with  respect  to  mission  objectives,  mode  end 
task  management,  and  aoftwara  parameters 

-  Interpretation  of  response  to,  and  Integration  of,  human  control  Into  the  system  functionality 

-  Collection,  maintenance,  and  reporting  of  ayatem  hardware  and  software  status,  and  operational 
functionality 

-  Response  to  hardware  and  software  failure  detection  to  preserve  mission  effectiveness 

-  Plight  control  change  management  and  response 

-  Reintegration  of  recovered  hardware  or  software  functions 

-  Assurance  of  s  distributed  data  base  consistency  and  Integrity,  management  of  access  to  that 
shared  data 

-  Preservation  and  collection  of  data  required  for  continuity  of  system  functionality  across 
failure  recovery  points 

-  Management  of  communications  access  to  ensure  optimal  use  of  communication  resources  and  correct 
addressing  of  dots  messages 

-  Assurance  of  the  security  of  classified  data 

The  operating  system  Is  partitioned  Into  three  elements:  (1)  the  kernel  executive  which  provides  those 
functions  common  to  sll  processors,  (2)  the  distributed  executive  which  provides  for  decentralized 
system  control  In  each  processor,  (3)  system  executive  which  provides  the  monitoring  of  system  state 
and  reconfiguration  based  on  mission  requirements  and  detected  system  failures.  Figure  2  depicts  the 
Interrelationship  of  the  three  elements. 

OPERATIONAL  C0HC8PT 


The  PAVE  PILLAR  architectural  concept  was  developed  to  support  aircraft  operations  from  deployed 
locations  with  a  minimum  of  support.  This  architecture  supports  the  resource  sharing  of  core  data  and 
signal  procssslng  resources  and  is  constructed  of  a  set  of  common  modules  that  specifically  support  a 
two— level  maintenance  concept.  This  srchltecturs  supports  high  degrees  of  systems  availability  and 
reliability.  This  is  accomplished  through  the  application  of  spare  signal  and  data  processing 
resources  st  the  system  level  so  that  backup  services  are  provided  when  the  primary  sources  fail.  Tn 
addition,  the  architecture  supports  graceful  degradation  in  that  when  spare  resources  are  exhausted 
remaining  resources  csn  be  assigned  to  the  highest  priority  functions  on  a  mission  basis. 

COWON  MODULES 


The  PAVE  PILLAR  architecture  Is  physically  comprised  of  a  number  of  "building  blocks"  cslled  common 
modules.  A  comion  module  Is  slssd  to  contain  the  circuitry  to  perform  a  complete  digital  processing 
function  Including  lnterfacs  control  and  health  diagnosis.  The  approach  for  PAVE  PILLAR  Is  to  develop 
common  modules  from  a  limited  VHSIC  chip  set  and  than  develop  systems /subsystems  which  utilise  the 
common  modules.  The  exact  composition  of  ths  VHSIC  chip  set  will  depend  on  the  evolution  of  that 
technology  program,  while  the  members  of  ths  comson  module  family  will  be  subject  to  PAVE  PILLAR 
avionic  system  design  considerations. 

A  number  of  common  modules  csn  be  built  up  from  s  family  of  VHSIC  chips  which  in  turn  can  be  grouped 
to  form  the  basis  for  any  one  of  the  avlonlca  subsystems  depicted  in  Figure  3.  Certain  non-common 
modules  will  undoubtsdly  be  required  for  some  specific  subsystem  Implementation,  however,  the 
reduction  in  numbers  of  spares  types  rsqulred  as  a  result  of  common  module  usage  will  provide  a 
significant  coat  and  effsctlvsnss  Improvement. 

The  Avionics  Laboratory  has  undertaken  the  design  end  development  of  two  common  module  sets;  the  VHSIC 
1750A  Date  Processor  and  the  VHSIC  Common  Signal  Processor.  These  modules  are  being  designed  with 
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stringent  requirements  for  both  extremely  lov  failure  rates  and  high  fault  detection  and  fault 
Isolation  capabilities.  Fault  Isolation  to  the  single  module  level  vlll  be  accomplished  by  on-board 
Built-In-Teat  (BIT)  circuitry  at  the  chip  level  and  multi-tiered  self  teat  software.  The  use  of  a 
modular  concept  will  permit  the  maintenance  personnel  to  perform  on-board  diagnosis  and  replacement  of 
the  avionics  at  the  module  level  with  no  auxiliary  ground  equipment. 

This  capability  then  leads  one  to  conclude  that  a  two-level  avloolcs  maintenance  concept  might  be 
reallsaable.  Figure  4  shows  the  Impact  of  various  maintenance  concepts.  The  current  three  level 
maintenance  approach  consists  of  flight  line,  Avionics  Intermediate  Shop,  and  depot/factory  diagnosis 
and  repair.  To  Illustrate  the  benefits  of  changing  from  a  three-level  to  a  two-level  maintenance 
concept  an  in-house  study  to  examine  the  relative  life  cycle  cost  of  aeveral  combinations  of 
maintenance  concepts  and  technology  integration  was  conducted.  As  shown  here,  the  costs  consist  of 
operations  and  support  plus  the  Avionics  Intermediate  Shop  and  spare  parts  to  support  1000  aircraft 
for  20  years  at  a  flying  rate  of  300  flight  hours  per  aircraft  per  year.  All  costs  are  stated  In  FY84 
dollars.  The  first  column  represents  today's  technology  -  F-16  A/B  -  utilising  the  standard 
three-level  maintenance  with  removal/replacement  of  LRUs  at  the  flight  line.  In  column  B  the 
three-level  maintenance  concept  la  retained  and  LRUs  are  etlll  used,  but  VHSIC  technology  has  been 
incorporated  and  a  fault  tolerant  design  through  extensive  built-in-test  has  been  Introduced.  These 
steps  reduce  our  cost  for  operating  and  maintaining  the  1000  aircraft  fleet  by  nearly  20Z.  In  the 
next  step,  where  the  Avionics  Intermediate  Shop  Is  eliminated  and  everything  elae  is  kept  the  same  as 
B.  there  Is  a  further  reduction  In  cost  of  over  $200M.  Finally.  Introduction  of  standard  modules  and 
elimination  of  LRUs  In  favor  of  line  replaceable  standard  modules,  provides  a  further  reduction  In 
cost  to  approximately  one-half  of  the  current  ownership  bill.  While  these  numbers  aren't  hard  and 
fast  they  do  provide  an  indication  of  the  alseable  cost  gains  which  can  be  realised  through  the 
application  of  PAVE  PILLAR  technologies. 

TECHNOLOGY  TRANSPARENCY 


The  building  block  approach  espoused  In  this  article  permits  not  only  the  inltlel  development  of  e 
highly  flexible  avionics  suite,  but  also  the  continued  development  and  Integration  of  Pre-Planned 
Product  Improvements  (P9I) .  This  Is  accomplished  within  the  architecture  by  the  concept  of  standard 
data  buaas  (Parallel  Interface  (PI).  Teat  and  Maintenance  (TM) ,  High  Speed  Data  Bus  (HSDB))  and 
networks  (SDDN,  VDDR,  DEN.  Data  Flow  Network).  This  concept  Is  implemented  by  Form.  Fit.  Function  end 
and  Interface  (F*I)  specif Icat lona  for  each  module  type  thereby  permitting  different  designs  by  vendor 
for  each  module  type  and  specific  vendor  module  design  modification  dependant  upon  technological 
improvements . 

Due  to  the  open  architecture,  as  new  building  blocks  are  identified  they  can  be  readily  integrated 
Into  the  avionics  system  thus  permitting  the  performance  upgrade  to  an  existing  aircraft  at  a 
relatively  lov  cost.  New  Investigations  have  already  begun  In  the  areas  of  parallel  processing, 
artificial  Intelligence  processing,  and  optical  processing.  The  Intent  la  to  integrate  these  advanced 
processing  elements  Into  the  PAVE  PILLAR  architecture  lf/vhen  they  become  viable  both  opei. .* ‘onally 
and  loglstlcally. 

In  summary,  a  PAVE  PILLAR  avionics  archltactura  will  result  In  dramatic  improvements  in  availability, 
mission  ef f ectlvenss ,  and  cost  of  ownership.  For  reasons  of  mobility,  logistics  cost  control,  and 
sustsre  maintenance  of  aircraft  at  forward  sltas,  a  tvo-leval  maintenance  concept  with 
line- replaceable-modules  la  endorsed  by  the  PAVE  PILLAR  system.  PAVE  PILLAR  plana  to  achieve  these 
benefits  and  goals  through  advances  in  technology,  and  a  systems  approach  to  avionics  integration. 

PAVE  PILLAR  la  expected  to  provide  the  generic  integration  approach  and  architecture  that  will  act  as 
the  foundation  for  avionics  development  in  next-generation  Air  Force  aircraft. 
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Summary 

Pave  Pillar  architecture  incorporates  a  “Common  Signal  Processor  (CSP)“  concept  as  a  key 
building  block  of  a  USAF  advanced  avionics  suite.  This  CSP  concept  embodies  the  use  of  standard 
Internal  interfaces,  a  family  of  modules,  use  of  the  programing  language  Ada  to  express  application 
program  for  the  data  processors  uithin  CSP,  and  the  use  of  a  Graph  Notation  to  represent  signal 
processing  functions  for  the  signal  processing  components  of  CSP.  The  modularity  permits  upgrading  any 
hardware  or  software  component  with  minimal  disruption  to  the  rest  of  the  design.  CSP  Is  an  "open 
architecture"  In  that  the  Interfaces  and  module  specifications  are  non-proprietary  and  can  be  built  by 
other  vendors.  The  paper  will  address  the  system  concept,  hardware  architecture,  and  software 
philosophy  comprising  the  CSP  System.  It  will  describe  In  general  terms  how  the  CSP  hardware  works  and 
Its  expandability.  Existing  modules  will  be  listed  and  potential  future  modules  Identified.  A  brief 
description  of  the  Graph  Notation  and  its  advantages  will  be  provided.  The  CSP  Local  Operating  System 
capabilities  and  use  will  be  summarized.  Application  studies  to  determine  the  suitability  of  the  CSP 
concept  for  different  avionic  applications  such  as  radar,  electronic  warfare,  communications,  and 
electro-optical  sensors  will  be  briefly  summarized.  The  role  of  MIL-STD-1750A  processors  In  CSP  and 
their  limitations  will  be  touched  on,  and  future  upgrades  to  32-bl t  machines  discussed. 

Background 

AFWAL  has  been  pursuing  the  development  of  generic  digital  signal  processing  architectures  for 
avionics  since  the  early  1980's.  This  Is  In  response  to  a  need  to  reduce  the  cost  of  signal  processing 
subsystems,  the  time  required  to  field  them,  and  the  difficulty  encountered  In  maintaining  and 
upgrading  them.  Most  current  signal  processors  are  special  purpose  designs  with  little  flexibility. 
Circuit  technologies  available  In  the  1970‘s  did  not  permit  highly  programnable,  modular  designs  within 
the  size,  power,  and  weight  constraints  of  avionics.  With  the  rapid  advances  In  VLSI  technology,  order 
of  magnitude  Increases  In  performance  are  possible  compared  with  earlier  circuitry.  Hence,  competitive 
performance  common  signal  processor  architectures  have  become  feasible. 

Several  exploratory  development  In-house  and  contractual  efforts  were  conducted  which  led  up 
to  the  Initiation  of  the  advanced  development  CSP  System  project.  In-house  activities  concentrated  on 
evaluation  of  existing  digital  signal  processors  and  identf fication  of  signal  processing  requirements 
across  the  avionic  disciplines  of  radar,  integrated  communication/navigation,  and  electronic  warfare. 
Parallel  contract  were  let  to  AT&T  8ell  Labs  and  TRW  to  do  additional  requirements  studies,  design,  and 
simulation  of  generic  signal  processing  architectures.  These  efforts  helped  confirm  belief  In  the 
feasibility  of  developing  a  widely-applicable  comon  signal  processor  that  would  be  performance 
competitive.  The  results  of  these  efforts  were  used  In  the  formulation  of  the  requirements,  baseline 
architecture,  and  performance  goals  for  the  CSP  project.  IBM  Federal  Systems  Division,  Manassas,  VA, 
was  awarded  the  CSP  advanced  development  contract  In  late  1984.  This  effort  is  developing  the 
architecture,  hardware,  software,  and  support  equipment  to  demonstrate  the  CSP  System  and  Is  the  basis 
for  much  of  the  Information  in  this  paper. 

The  first  CSP  unit  to  be  delivered  will  be  Incorporated  Into  the  Ultra-Reliable  Radar  (URR)  as 
its  principal  processing  system.  The  URR  Is  an  advanced  avionics  radar  system  under  development  by 
AFWAL  and  has  a  very  demanding  processing  requirement.  Hence  It  provides  an  excellent  test  for  whether 
or  not  CSP  can  meet  its  performance  goals.  The  Initial  radar  capabilities  to  be  developed  are 
air-to-air  modes.  Studies  were  done  by  IBM  on  the  CSP  contract  to  assess  the  suitability  of  the  CSP 
architecture  for  Communication,  Navigation,  and  Identification  of  friend  or  foe  (CNI),  Electronic 
Warfare  (EW),  and  Electro-Optical  (EO)  processing.  These  studies  showed  that  the  core  architecture  Is 
a  good  match  for  their  requirements;  several  new  processing  element  module  types  were  Identified  that 
would  be  desirable  to  develop  to  efficiently  handle  the  signal  processing  functions  In  these  additional 
areas.  This  will  be  discussed  further  later  in  the  paper. 

CSP  System  Concept 

The  CSP  System  can  be  viewed  as  a  multiprocessor  designed  to  permit  the  Processing  Elements 
(PEs)  to  process  at  the  highest  utilization  rate  as  practical  for  a  given  application.  (The  PEs 
perform  the  signal  processing  “number  crunching.")  To  this  end,  a  par„llel  Data  Network  (ON)  provides 
high  bandwidth  point-to-point  data  paths  for  PEs  to  connect  to  Global  Memories  (MSs),  Sensor  Interfaces 
(Sis),  and  other  PEs.  (Figure  1  provides  a  block  diagram  of  the  CSP  hardware  architecture.)  GMs 
provide  a  large  storage  area  for  holding  sensor  data  until  a  PE  is  ready  to  process  it  and  for  holding 
intermediate  computational  results  between  processing  steps.  The  GM  may  hold  reduced  data  for  later 
post  processing  by  a  data  processor,  a  MIL-STD-1750A  module,  and  transfer  to  other  avionic  system 
components  over  a  system  bus.  The  Element  Supervisor  Unit  (ESI1)  Is  a  1750A  data  processor  designed  to 
efficiently  control  Functional  Elements  (FEs),  which  Is  the  general  name  given  for  any  PE,  GM,  or  I/O 
Module  connected  to  the  network.  By  dedicating  ESlls  to  pairs  of  FEs,  it  is  possible  to  ensure  that 
process  control  activities  (1/0  scheduling,  task  scheduling,  etc)  do  not  Idle  PEs  or  other  FEs. 

In  order  for  CSP  to  be  widely  applicable  with  competitive  performance  and  cost-effectiveness, 
it  must  be  modular  so  that  It  can  be  configured  for  the  processing  needs  of  the  application.  The  Oata 
Network  (DN)  is  the  key  to  achieving  this.  It  can  be  configured  in  a  variety  of  ways  (see  the  Data 
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Network  Operations  section).  It  must  be  possible  to  design  new  FEs  that  Interface  to  the  ON  and  ESU 
and  use  much  of  the  existing  software  without  re-work. 

Since  multiprocessors  are  Inherently  more  difficult  to  program  than  uniprocessors.  It  was 
judged  necessary  to  provide  High  Level  Languages  (HLLs)  In  which  It  could  be  programned.  Ada  Is 
provided  for  programing  “  Application  Command  Programs"  (ACPs)  within  the  1750A  Data  Processors.  A 
directed  flow  graph  language,  called  Graph  Notation,  is  provided  for  programing  the  signal  processing 
portion  of  the  system.  It  permits  the  programmer  to  describe  parallel  FE  tasks  conveniently.  The  CSP 
hardware  and  Its  resident  Local  Operating  System  (LOS)  may  be  viewed  as  a  ‘virtual  multiprocessor' 
system  that  executes  ACPs  and  signal  processing  graphs.  ACPs  control  graphs  through  a  set  of  LOS 
services.  Off-line  support  software  tools  permit  the  preparation  and  simulation  of  ACPs  and  graphs 
prior  to  execution  on  the  CSP  hardware. 

Reliability,  maintainability,  and  availability  received  strong  emphasis  In  the  CSP  project. 
VLSI  circuits  are  designed  with  significant  selftest  capability.  Modules  Include  fault  log  devices  for 
storing  faults  that  may  occur  In  operation.  The  system  Includes  separate  maintenance  buses  for 
recording  faults  and  accessing  them  operationally  and  for  diagnostic  purposes.  The  system  Is  designed 
for  on-equipment  maintenance  In  an  operational  setting-,  that  Is,  sufficient  testability  Is  provided  so 
that  failed  modules  can  be  Identified  with  minimal  external  equipment  and  replace. 

Adequate  technology  transparency  Is  an  Important  goal  for  the  CSP  project.  In  order  to  avoid 
obsolescence.  It  must  be  possible  to  upgrade  FEs  and  data  processor  with  Improved  circuitry  while 
retaining  much  of  the  existing  software  and  hardware.  By  writing  software  In  Ada  and  Graph  Notation, 
significant  hardware  transparency  Is  achieved  for  application  software.  FEs  are  defined  with  complete 
functions  contained  within  the  module,  thus  simplifying  the  Interfaces  and  permitting  performance  and 
function  evolution  within  each  module  without  disrupting  other  system  components.  Maintaining  an  open 
architectures  will  permit  other  vendors  to  develop  new  modules  to  better  meet  their  unique  requirements 
than  might  be  available  within  the  generic  set  of  modules. 

Data  Network  Operation 

The  Data  Network  (DN)  provides  high  speed  parallel  paths  between  pairs  of  Functional  Elements 
(FEs)  attached  to  It.  It  Is  designed  so  that  a  variety  of  configurations  can  be  used.  It  Is 
implemented  with  a  VLSI  circuit  called  the  "Data  Network  Switch"  (DNS),  which  Is  a  switch  with  8  16-bit 
ports.  Each  port  has  4  control  and  parity  lines  associated  with  it.  It  permits  any  port  to  be 
switched  to  any  other  port.  DNSs  can  be  cascaded  to  form  a  multi-level  network.  Paths  through  the 
network  are  set  up  by  routing  Information  contained  In  the  header  of  each  message.  Up  to  4  levels  of 
routing  can  be  used  with  the  circuit  DNS  circuit  design. 

The  CSP  Breadboard  (BB)  Is  configured  with  8  Data  Network  Element  (DNE)  modules  which  provide  24 
ports  with  32-bit  data  paths.  Each  DNE  uses  2  DNS  circuits  which  are  connected  to  provide  12  external 
16-bit  ports.  The  16-bit  ports  can  be  viewed  as  a  16-bit  slice  and  combined  with  another  port  to 
provide  a  32-bit  path.  The  second  port  can  be  on  the  same  module  or  a  second  parallel  module.  Thus 
both  16-bit  and  32-bit  networks  can  be  configured  In  a  variety  of  ways.  Figures  2  and  3  Illustrate  the 
DNE  module  layout  and  the  CSP  BB  DN  design,  respectively.  Table  1  lists  some  of  the  DN  configurations 
that  are  possible  with  the  DNS  chip  design  and  DNE  module 
design. 

The  control  of  the  DN  Is  distributed  In  the  sense  that  each  message  contains  the  routing 
Information  to  determine  Its  destination.  There  Is  no  centralized  control  mechanism;  this  makes  the 
design  readily  expandable.  DNs  with  multiple  levels  of  switching  contain  the  possibility  that  messages 
may  encounter  busy  nodes  within  the  DN;  that  Is,  It  Is  a  blocking  network.  The  alternative,  a  full 
crossbar  switch  which  provides  a  direct  path  from  every  port  to  every  other  port,  requires  considerably 
more  hardware  and  Interconnections.  It  becomes  Impractical  for  more  than  a  limited  number  of  ports. 
If  a  message  encounters  a  busy  node,  the  design  Includes  the  mechanisms  needed  for  retries.  Software 
may  choose  to  re-route  the  message  over  an  alternate  path.  Initial  use  of  CSP  has  shown  that  the  DN 
has  not  proven  to  be  a  bottleneck  for  system  operation. 

The  DN  permits  data  to  be  transferred  at  one  word  per  system  clock  once  the  path  Is  established. 
A  one-clock  delay  Is  added  for  each  DN  node  through  which  the  message  must  pass.  Once  a  message  has 
been  initiated,  path  establishment  through  the  DN  Is  a  hardware  function  requiring  only  a  modest  number 
of  clock  cycles  to  achieve. 

Element  Supervisor  Unit  (ESU) 

The  ESU  module  Is  a  1750A  processor  designed  to  efficiently  control  attached  FEs  and  synchronize 
Its  activities  with  other  ESUs.  Two  local  buses  are  provided  to  connect  to  FEs:  the  Element  Control 
Bus  (ECB)  and  the  Element  Maintenance  Bus  (EMB).  The  ECB  provides  Direct  Memory  Access  (DMA)  to  ESU 
local  memory  by  DMA  controllers  on  the  attached  FEs.  This  capability  Is  used  to  efficiently  fetch  Data 
Network  channel  control  blocks,  FE  processing  control  blocks  (signal  processing  "Macro"  control  blocks 
for  PEs,  or  read/write  control  blocks  for  I/O  Modules),  or  make  data  transfers  from  FE  local  store  to 
ESU  local  store.  The  El®  Is  a  serial  bus  for  accessing  test  and  maintenance  information  within  the  FE 
and  providing  It  to  LOS  resident  within  the  ESU. 

The  ESU  also  connects  to  a  system-wide  linear  control  bus,  the  Parallel  Internal  Bus  (Pi-Bus),  and 
to  a  system-wide  serial  test  and  maintenance  bus,  the  TM-Bus.  The  Pi-Bus  Is  used  to  pass  tokens  from 
one  ESU  to  another  Indicating  events  within  the  execution  of  ACPs  and  graphs,  for  transferring  sensor 
control  commands,  passing  computed  graph  results  to  data  processors  for  post  processing,  or 
coMiunlcatlng  with  system  I/O  modules.  The  ESU  PI-  Bus  Interface  logic  Includes  extra  hardware  to  make 
token  passing  very  efficient. 

Within  the  CSP  Breadboard  (BB),  the  ESU  Is  used  to  "emulate"  the  VHSIC  1750A  modules  (see  Figure 


1),  since  these  modules  were  not  scheduled  to  be  ready  In  time  for  the  BB.  Hence,  all  1750As  within 
the  system  are  ESUs. 

Floating  Point  Processing  Element  (FPPE) 

The  FPPE  Is  a  pipelined  processor  with  2  parallel  floating  point  computational  paths  capable  of 
performing  5  floating  point  operations /machine  cycle  burst  rate  or  a  complex  floating  point  Fast 
Fourier  Transform  (FFT)  butterfly  operation  once  every  2  cycles.  As  an  FE,  it  Is  controlled  by  an  ESU 
over  the  local  ECB  and  EMB  interfaces  and  is  connected  to  the  ON  for  data  transfers.  It  contains  local 
memory  divided  into  2  logical  banks  that  operate  as  “swing"  or  "ping  pong"  buffers  with  one  bank 
connected  to  the  network  and  the  other  to  the  FPPE  data  flow  logic.  When  a  task  com-  pletes,  the  banks 
are  switched.  Each  bank  holds  16K  words  of  storage. 

The  FPPE  contains  microstore  for  holding  its  microprograms,  referred  to  as  "Macros."  Local 
sequencers  control  Macro  execution.  Each  Macro  execution  requires  a  "Macro  Control  Block"  (MCB)  to 
specify  its  starting  address  and  a  set  of  execution  parameters.  These  MCBs  are  stored  in  ESU  memory 
and  accessed  by  the  FPPE  over  the  ECB  using  DMA  transfers.  A  string  of  Macros  comprise  a  task.  The 
ESU  initiates  a  task  with  an  I/O  transfer  to  the  FPPE  providing  the  sequencer  with  the  starting  address 
of  a  MC8  string  in  ESU  local  memory.  When  the  task  Is  completed,  the  ESU  Is  notified  by  the  FPPE. 

The  FPPE  is  designed  to  permit  continuous  processing  to  be  maintained.  While  the  FPPE  is 
processing  one  task  using  data  in  one  bank  of  local  store,  the  controller  Is  unloading  results  from  the 
previous  task  out  of  the  other  bank  of  memory  and  then  loading  input  data  for  the  next  task.  If  this 
can  be  done  before  the  current  task  completes,  the  FPPE  will  remain  busy. 

The  FPPE's  primary  data  type  Is  32-bit  floating  point  with  a  24-bit  fractional  part  and  an  8-blt 
exponent.  It  also  operates  on  extended  precision  floating  point  with  a  47-bit  fraction  and  8-blt 
exponent  and  16-bit  fixed  point  data  types.  Basic  operations  Include  add,  subtract,  multiply,  compare, 
logical  OR,  AND,  XOR,  data  dependent  branches,  sine,  cosine,  square  root,  arctangent.  A  lookup  table 
facility  is  Included  to  implement  complex  functions.  A  separate  coefficient  memory  is  provided  for 
storing  constants;  this  is  useful  for  many  signal  processing  computations  and  complex  functions. 

Global  Memory  (GM) 

The  GM  provides  a  large  memory  storage  element  for  holding  digitized  sensor  data,  intermediate 
computational  results  for  signal  processing  PEs,  and  final  reduced  data  for  later  transfer  to  data 
processors  for  post  processing.  It  also  is  used  to  store  program  loads,  code  and  Initial  data,  for  all 
of  the  computational  units.  Use  of  global  memory  provides  a  way  to  decouple  data  arrival  from 
succeeding  processing  steps  and  to  decouple  those  processing  steps  from  each  other;  in  this  sense,  it 
differs  from  "hardwired"  signal  processors  with  a  "flow-through"  sort  of  design  that  passes  the  data 
from  element  to  element.  The  high  bandwidth  DN  makes  this  concept  workable. 

The  GM  Is  an  Intelligent  memory  In  that  it  provides  six  hardware-  supported  address  modes  for 
accessing  data  In  It.  These  are 

( 1 )  Single  c  rcular  Queue 

(2)  Multiple  Circular  Queue 

(3)  Corner  'urn  Queue 

(4)  Coordi  ite  Rotation 

(5)  Random  Ac:ess  Queue 

(6)  Buffer 

and  they  provide  the  user  with  the  ability  to  efficiently  store  and  retrieve  data  In  the  ways  reeded 
for  signal  processino  applications.  Two  dimensional  arrays  of  data  can  be  manipulated  efficiently, 
such  as  encountered  m  "Synthetic  Aperture  Radar"  (SAR)  applications,  for  instance.  The  ability  to 
define  a  variety  of  "Storage  Objects"  is  provided  In  the  Graph  Notation,  and  the  CSP  System  (LOS  and 
the  hardware)  performs  the  operation  for  the  user,  relieving  him  of  specifying  the  details  of  the 
operation. 

The  current  CSP  GM  provides  1  million  32-bit  words  of  storage.  The  addressing  logic  permits 
expansion  to  4  million  words.  The  GM  has  three  ports:  the  DN,  Element  Control  Bus  (ECB),  and  the 
Element  Maintenance  us  (EMB).  The  GM  bandwidth  matches  the  DN  port  bandwidth  of  1  32-bit  word/- 
system  clock.  The  m*.  ory  Includes  an  8-bit  Error  Correcting  Code  (ECC)  that  corrects  any  errors  In  any 
one  4-blt  nibble  wit  in  the  32-bit  data  word.  A  logical  to  physical  mapping  mechanism  is  provided  to 
support  dynamic  memor<  usage.  A  fixed  size  paging  scheme  Is  used  to  avoid  memory  fragmentation.  The 
memory  Is  organized  ■’to  4  banks  of  256K  x  40  bits  which  are  accessed  in  an  interleaved  fashion;  this 
permits  slower  memory  circuits  to  be  used  and  still  match  the  DN  bandwidth. 

Sensor  Interface  (SI] 

The  SI  module  is  a  high  speed  port  for  connection  to  a  sensor  In  a  point-to-point  manner  or  it  may 
be  used  In  a  Ring  network  configuration  connecting  a  series  of  CSPs  together.  The  current 
implementation  Is  a  wire  version  with  separate  32-bit  data  paths  for  transmit  and  receive  (2  bits  of 
parity  are  provided  for  each  channel  also).  Consideration  was  given  In  the  design  for  eventual  upgrade 
to  fiber  optics.  Data  Is  transferred  at  a  maximum  rate  of  one  word  every  2  machine  clock  cycles.  In 
full  duplex  mode,  one  channel  may  operate  continuously  while  the  other  operates  In  a  pulsed  manner. 

The  SI  Module  Is  controlled  by  an  ESU  over  the  ECB  and  EMB  interfaces.  It  connects  to  the  Data 
Network,  which  operates  at  a  rate  of  one  word  per  machine  cycle.  The  SI  contains  3  banks  of  local 
memory  which  may  be  switched  from  one  interface  to  another  when  they  are  filled  or  unloaded.  Transfers 
nay  take  place  from  ESU  local  memory  to  the  SI  local  memory  and  vice  versa;  from  the  Data  Network  to 
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and  from  the  SI  local  memory;  and  from  SI  local  memory  to  and  from  the  external  SI  Interface. 

A  minimal  Message  protocol  Is  available  for  when  the  SI  Is  In  point-to-point  Link  node;  a  Ring  protocol 
is  available  for  operation  in  the  Ring  Network  node.  Messages  consist  of  franes  consisting  of  several 
header  words,  fron  0  to  4k  data  words,  and  several  trailer  words.  ESU  nanagenent  of  the  SI  is  sinilar 
to  the  other  EEs:  Message  control  blocks  are  stored  in  ESU  progran  store  and  are  accessed  over  the  ECB 
by  the  SI  controller  logic.  Each  nessage  requires  a  control  block.  A  string  of  control  blocks  nay  be 
processed  by  the  SI  without  ESU  Intervention;  this  Is  an  SI  "task"  to  the  graph  programner.  The  ESU 
initiates  an  SI  task  with  an  I/O  coanand  providing  Information  to  the  SI  about  the  control  block 
string. 

Systen  I/O  Modules 

The  CSP  BB  Includes  a  MIL-STD-1553B  I/O  Module  for  coamunlcatlon  with  other  avionic  equipment 
having  that  bus  port  available.  A  High  Speed  Data  Bus  (HSD6)  I/O  Module  will  provide  system 
communication  in  the  future. 

Support  Modules 

In  order  to  complete  the  CSP  BB,  various  support  modules  must  be  Included.  A  Timing  and  Control 
Generator  (TCG)  provides  the  system  clocks  needed  for  the  various  FEs  and  system  buses.  A  User  Console 
Interface  (UCIF)  provides  a  laboratory  connection  to  the  User  Console  (UC);  It  permits  the  UC  to 

control  the  CSP  System.  An  IEEE-488  bus  connects  the  UC  to  the  UCIF;  the  UCIF  can  be  viewed  as  a 

gateway  to  the  Pi-Bus  and  TM-Bus  within  CSP.  The  TM-Bus  permits  It  to  control  any  ESU.  The  Pi-Bus 
permits  the  UC  to  efficiently  transfer  data  to  any  ESU  or  selectively  monitor  PI-  Bus  activity. 

Distributed  DC  to  DC  power  convertor  modules  are  used  to  supply  power  to  the  logic  modules.  A 
laboratory  source  is  used  to  supply  the  Intermediate  DC  voltage  to  the  convertor  modules.  Two  modules 
are  Included  for  PI-  Bus  and  TM-Bus  terminations. 

Graph  Notation 

A  CSP  Graph  is  a  high  level  method  for  representing  the  signal  processing  functions  executed 
within  CSP  using  data  flow  techniques.  It  Is  one  of  two  basic  program  units  used  to  program  the 
machine,  the  other  being  an  Ada  Application  Command  Program  (ACP).  A  "node"  (task)  within  a  graph 
"fires"  (executes)  when  all  of  its  Inputs  are  available  and  Its  output  buffers  are  empty.  A  task  does 
not  retain  data;  data  Is  passed  through  the  graph  links  to  the  next  node  in  data  flow  fashion.  Graphs 

start  executing  after  an  ACP  has  “instantiated"  the  graph  (linked  and  loaded  the  graph  from  a  "graph 

realization"  stored  in  a  GM  to  form  a  "graph  instance"),  enabled  it.  and  input  data  Is  available. 

An  ACP  controls  a  graph  through  a  set  of  Local  Operating  System  (LOS)  Services.  An  ACP  may  provide 
Graph  Constants  as  parameters  for  a  graph  In-  stantiatlon  to  specialize  It  for  a  particular  function. 
Graph  Variables  may  be  supplied  to  an  executing  graph  for  changing  its  parameterization;  Graph  Switches 
may  disable  or  enable  nodes  in  the  graph.  An  ACP  may  connect  one  Instance  of  a  graph  to  another 
Instance,  or  delete  a  previously  created  Instance.  ACP  tasks  may  be  connected  to  CSP  Graphs  through 
graph  Interfaces. 

A  CSP  Graph  provides  a  convenient  notation  for  specifying  tasks  for  CSP  Functional  Elements  (FEs) 
that  relieve  the  programner  from  having  to  specify  low  level  hardware  operations  yet  use  the  full 
capabilities  of  the  various  FEs.  Two  types  of  GM  Storage  Objects,  Queue  and  Buffer,  may  be  specified 
that  permit  the  full  range  of  GM  addressing  modes  to  be  used  to  access  data.  FPPE  tasks  consist  of 
Macro  (primitive)  strings  that  perform  signal  processing  functions  on  a  set  of  input  data  loaded  into 
FPPE  local  store  and  unloaded  when  the  task  Is  finished.  Graph  Interface  tasks  may  be  specified  for 
transferring  messages  on  the  CSP  data  paths  (the  Data  Net-  work,  Pi-Bus,  and  Sensor  Interface).  A 
sample  graph  for  a  Spotlight  Synthetic  Aperture  Radar  (SAR)  function  is  provided  In  Figure  4. 

Local  Operating  System  (LOS) 

LOS  Is  the  resident  real-time  operating  system  within  the  1750A  data  processors  that  controls  the 
CSP  System  and  “runs"  the  ACPs  and  Graphs.  LOS  Services  provide  the  interface  through  which  the  ACP 
commands  the  sensor,  Interacts  with  other  Pave  Pillar  architecture  subsystems,  conanunlcates  with  other 
ACPs,  and  controls  the  graphs.  LOS  Includes  an  "Availability  Management  System  (AMS)"  that  monitors 
hardware  and  software  error  reports,  filters  these  reports,  stores  them  locally  and  in  non-  volatile 
module  Fault  Log  devices,  and  takes  corrective  actions.  It  includes  system  startup  capability  and  debug 
features  for  development  purposes.  It  includes  system  resource  management  functions  for  controlling 
what  Is  a  distributed  "virtual  multiprocessor."  It  controls  the  logical  to  physical  mappings  for 
management  of  the  Global  Memories  (GMsJ. 

LOS  Is  divided  into  three  components:  the  Subsystem  Master  (SSM)  LOS  resident  In  the  controlling 
I750A  data  processor,  the  SSM  Support  Processor  (SSMSP)  restdent  In  a  secondary  1750A,  and  ESU  LOS 
resident  In  each  ESU  controlling  FEs.  ACPs  are  resident  in  SSM  and  SSMSP  1750As;  ESUs  only  contain  LOS 
code  and  data.  ESU  LOS,  a  single  progran,  is  capable  of  controlllrj  any  FE  type:  FPPE,  GM,  or  SI.  The 
critical  function  of  ESU  LOS  Is  to  schedule,  dispatch,  and  run  graph  tasks  efficiently  in  order  to 
avoid  Idle  FEs.  This  means  that  Pi-Bus  messages.  Data  Network  messages,  and  ECB  message  transfers  must 
be  handled  efficiently.  LOS  essentially  Implements  the  graphs  as  sets  of  data  tables  and  control  block 
strings  defining  the  graph  functions  to  LOS  and  the  attached  FEs.  Graph  Instantiation  consists  of  the 
loading  of  these  tables  and  strings  in  ESUs  appropriately.  Task  scheduling  is  done  with  a  set  of 
prioritized  First-In-First-Out  (FIFO)  queues;  task  dispatching  is  done  with  a  single  non-lnterruptible 
FIFO  queue. 
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Support  Software  Environment  (SSE)  and  Support  Equipment 

Figure  5  provides  a  block  diagram  of  the  support  tools  comprising  the  CSP  SSE.  The  SSE  Is  hosted 
on  a  Digital  Equipment  Corp  (DEC)  VAX  computer  system.  The  CSP  Is  directly  controlled  by  a  PC  AT  User 
Console  (UC)  In  a  laboratory  environment.  Software  Is  downloaded  from  the  VAX  through  the  UC  to  the 
CSP.  The  SSE  Is  a  set  of  tools  for  preparing  and  simulating  (1)  Ada  Application  Comaand  Programs 
(ACPs),  (2)  signal  processing  Graphs,  and  (3)  FPPE  microprograms. 

An  Ada/1750A  Language  System  is  used  to  prepare  ACPs.  It  consists  of  a  compiler,  Macro  Assembler, 
Linkage  Editor,  PI-Bus-based  multiple  computer  simulator,  and  an  Ada  Debugger.  The  Debugger  Is  being 
extended  to  provide  symbolic  access  to  the  CSP  hardware;  It  currently  Is  usable  only  with  the 
simulator. 

A  Graph  Translator  translates  Graph  Notation,  written  In  textual  form.  Into  a  form  usable  by  the 
System  Level  Simulator  (SLS)  and  a  form  usable  by  LOS  for  loading  Into  the  hardware.  The  SLS  simulates 
the  control  flow  of  the  execution  of  a  CSP  Graph.  It  provides  loadings  on  CSP  resources:  FEs  and  all 
data  paths,  and  thus  Is  useful  for  analyzing  a  graph  design  to  see  If  It  Is  using  the  CSP  resources 
effectively.  It  does  not  execute  any  data;  rather,  It  Is  a  discrete  event  simulation  that  models  the 
execution  times,  message  passing,  memory  usages  using  estimates  derived  from  FPPE  microprogram 
simulations  for  FPPE  tasks,  built  In  LDS  overhead  times,  GM,  SI,  Pi-Bus,  and  DN  performance 
characteristics.  The  simulation  Is  maintained  to  reflect  an  accurate  model  of  the  actual  CSP  System 
performance . 

FPPE  tasks  are  written  In  a  microprogram  language,  assembled  with  a  Microassembler,  and  simulated 
on  a  Microsimulator.  The  Microsimulator  simulates  the  microprograms  ("Macros’)  at  the  machine  code 
level  with  a  clock-level  accuracy,  thus  providing  exact  execution  time  estimates  and  computational 
results.  Strings  of  Macros,  graph  tasks,  may  be  simulated  to  check  out  complete  graph  task  nodes.  A 
library  of  Macros  Is  maintained  which  may  be  re-used  In  various  applications.  A  System  Build  program 
generates  a  load  image  for  the  CSP  System  which  Includes  the  required  Macros  as  well  as  the  1750A  Ada 
and  assembler  load  Images  for  eventual  loading  In  CSP  through  the  User  Console. 

A  Support  Equipment  suite  Is  provided  which  consists  of  a  mini-CSP  that  can  be  used  to  simulate  SI 
sensor  Inputs,  15538  avionic  system  Inter-  actions,  and  accept  CSP  outputs.  It  consists  of  a  UC IF, 
several  ESUs,  a  CM,  two  Sis,  and  a  small  Data  Network.  It  Is  controller  ty  the  User  Console.  Since  It 
Is  a  CSP,  the  same  support  software  tools  are  used  to  prepare  Its  software  as  that  for  CSP. 

Application  Studies 

Requirements  and  design  studies  were  done  for  assessing  the  suitability  of  using  CSP  In  CNI,  EW, 
and  EO  signal  processing  subsystems.  Any  changes  to  the  core  architecture  components  and  addition  of 
new  modules  were  Identified.  Table  2  lists  the  core  architecture  modules,  support  modules,  and  a  set 
of  candidate  new  modules.  The  Vector  Signal  Processing  Element  (VSPE),  General  Purpose  PE  (GPPE) ,  Sort 
Enhanced  PE  (SEPE),  and  the  Bi-phase  Correlator  PE  (BCPE)  were  defined  and  preliminary  designs 
developed  during  the  application  studies. 

The  VSPE  Is  a  PE  that  processes  16-bit  fixed  point  data.  It  Is  a  pipelined  processor  with 
mlcroprogranwied  control  and  standard  FE  Interfaces:  DN,  ECB,  and  EMB.  It  Is  similar  In  architecture  to 
the  FPPE,  but  somewhat  less  flexible.  It  will  work  well  on  certain  types  of  well-  structured  vector  or 
matrix-oriented  algorithms,  Including  FFTs.  For  these  algorithms.  It  provides  a  times  four  ixprovement 
In  throughput  over  the  FPPE. 

The  GPPE  Is  a  data  processor  attached  to  the  Data  Network  and  control-  led  by  an  ESU  using  graph 
control  procedures.  It  Is  targeted  for  decision-intensive  signal  processing  functions  often  found  In 
EW  and  some  CNI  applications.  IBM  specified  It  as  a  1750A  processor,  but  a  Reduced  Instruction  Set 
Computer  (RISC)  class  machine  may  be  a  better  match  for  the  requirements.  A  CSP  configured  with  all 
GPPEs  can  be  viewed  as  a  general  purpose  parallel  processor  using  both  Ada  and  Graph  notation  as  Its 
programing  languages. 

The  SEPE  Is  designed  for  performing  EW  data  sorting  functions  at  very  high  speed.  These  functions 
are  often  performed  In  special  purpose  hard-  wired  units  today.  Associative  comparators  augment  the 
arithmetic  logic.  It  Is  suitable  for  filtering  long  pulse  descriptor  words  created  by  sensor  front-end 
units  into  clusters  for  later  post  processing.  It  creates  hit  counts  on  bins  and  thresholds  these.  Up 
to  four  compare  parameters  may  be  specified  per  bln.  Inputs  are  sorted  Into  tlme-of -arrival  order 
within  each  bln.  Input  word  lengths  may  be  16,  32,  64,  or  128  bits.  It  conforms 
to  the  FE  standard  hardware  and  software  Interfaces. 

The  BCPE  was  designed  to  perform  connunlcation-orlented  signal  processing  functions  such  as  found 
In  match  filter  algorithms,  preamble  detection  algorithms,  and  other  code  processing  functions.  It 
conforms  to  the  standard  FE  hardware  and  software  Interfaces. 

Advances  In  Data  Processor  Architectures 

CSP  uses  MIL-STD-1750A  processors  to  perform  the  data  processing  and  local  control  functions. 
This  USAF  standard  Is  a  16-bit  Instruction  Set  Architecture  (ISA)  with  16  16-bit  general  registers  and 
direct  address-  ability  to  64k  words  of  Instructions  and  64k  words  of  data.  It  Is  a  moderately  complex 
ISA  with  over  200  Instructions  and  a  dozen  address  modes.  To  address  more  than  64k  words,  a  page 
mapping  option  must  be  Implemented.  All  Implementations  must  Include  floating  point. 

Within  the  past  10  years,  it  has  been  demonstrated  that  "Reduced  Instruction  Set  Computers" 
(RISCsj  provide  a  more  cost-effective  use  of  circuitry  than  the  "Complex  Instruction  Set  Computers’ 
(CISCs).  Initial  demonstration  of  this  principle  was  done  at  IBM  on  a  project  known  as  801;  work  at 
the  University  of  California  Berkeley  In  the  early  '80's  continued  the  effort,  adding  some  Interesting 


register  usage  concepts  to  the  design,  and  also  coining  the  ter*  RISC,  RISC  designs  are  based  on  the 
principle  that  only  a  saall  set  of  basic  operations  for*  the  bulk  of  Instructions  most  computer 
programs  execute  and  that  the  Instruction  set  should  be  restricted  to  those  basic  Instructions,  fore 
complex  operations  can  be  synthesized  fro*  the  simpler  ones.  Historically,  the  development  of  CISCs 
can  be  partially  attributed  to  the  need  to  use  slow,  expensive  core  memories.  CPUs  were  micro  coded; 
adding  more  Instructions  and  address  nodes  was  Inexpensive  once  the  nlcroenglne  was  designed.  And  they 
provided  marginal  Improvements  In  program  size  and  execution  times.  With  solid  state  memories  more 
nearly  matching  logic  speeds  and  continually  Increasing  In  density,  the  CISCs  are  no  longer 
cost-effective. 

RISC  architectures  are  an  excellent  match  for  a  variety  of  avionic  data  processing  requirements. 
Many  avionic  applications  are  throughput  Intensive  rather  than  memory  Intensive.  RISC  take  less 
hardware  for  a  given  throughput.  Addressing  large  memories  directly  Is  straightforward  with  3?-b1t 
machines,  sl^llfylng  the  software  for  those  applications  needing  large  memories. 

D00  has  sponsored  the  several  RISC  projects,  notably  the  Defense  Advanced  Research  Projects  Agency 
(DARPA)  Microprocessor  without  Interlock-  ed  Pipeline  Stages  (MIPS)  projects.  These  projects  ore 
developing  both  silicon  VLSI  and  Gallium  Arsenslde  (GaAs)  VLSI  MIPS  microprocessors.  The  MIPS 
architecture  Is  based  on  work  done  at  Stanford  University.  AfWAL  has  initiated  exploratory  efforts  to 
assess  the  feasibility  of  combining  selected  stack  machine  features  with  RISC  principles  to  achieve  a 
more  High  Level  Language  (HLL)  compatible  32-bit  RISC  design. 

The  proposed  concept  of  a  conmon  32-bit  data  processor  architecture  Is  to  develop  an  ISA  with  a 
limited  number  of  subsets  which  would  permit  the  machines  to  be  tailored  to  the  application.  A  RISC 
core  set  of  Instructions  would  be  common  to  all  machines.  Baseline  additional  sets  Include  floating 
point,  supervisor/task  support,  memory  protection,  and  memory  mapping.  Good  multiprocessing  support 
Is  a  requirement.  The  ability  to  use  cache  memories  effectively  In  the  machine  designs  Is  necessary 
for  larger  applications. 

Within  Integrated  signal  and  data  processing  architectures  such  as  the  CSP  System,  such  a  32-bit 
processor  could  find  a  variety  of  applications.  It  could  serve  as  a  Functional  Element  (FE)  processing 
decision-intensive  signal  processing  functions  often  found  In  Ew  and  CHI.  Such  a  module  would  be 
designed  to  meet  the  CSP  Interfaces  and  operate  under  the  control  of  the  existing  LOS.  It  could  serve 
as  a  post  processor  In  place  of  the  1750A  modules.  It  could  eventually  replace  the  1750A  engine  within 
the  ESU  module,  although  this  will  require  re-targeting  the  LOS  to  a  new  ISA. 

Some  preliminary  studies  Indicate  that  RISC  processors  are  a  good  match  for  Artificial 
Intelligence  (AI)  applications.  If  this  Is  so,  that  may  aid  the  Introduction  of  those  techniques  Into 
real-time  avionic  applications  by  providing  a  significantly  higher  level  of  throughput  than  cur-  rently 
available. 

An  Important  development  area  for  32-bit  RISC  processors  for  avionics  Is  In  multiprocessor  systems 
using  software-transparent  comnon  memory.  Within  the  context  of  a  CSP  System,  the  functional  group 
(ESU  controlling  PEs,  GMs,  or  I/O  Modules)  may  evolve  to  a  form  of  shared  memory  multlpro-  cessor  with 
the  attached  modules  serving  as  peripheral  processors.  As  VLSI  designs  advance,  the  RISC  processor  can 
constitute  a  circuit  “macrocell";  signal  processing  functions  will  be  other  macrocells  on  the  same 
circuit.  RISC  macrocells,  cache  memory  macrocells,  pipeline  ALUs  macrocells,  etc,  could  comprise  a 
small  library  of  macrocells  from  which  different  parallel  processor  "nodes"  could  be  constructed.  Use 
of  a  microcircuit  technology  such  as  Gallium  Arsenide  (GaAs)  will  permit  a  very  fast  RISC  processor  PE 
to  be  built  when  that  technology  Is  nature  enough  to  support  VLSI  digital  circuits. 

Some  Lessons  Learned  To  Date  on  the  CSP  Project 

All  D00  computer  systems  developed  after  January  1984  are  required  to  use  the  Ada  programing 
language.  Since  CSP  was  started  In  Hovenber  1987,  It  falls  under  that  mandate.  CSP  Is  one  of  the  first 
major  avionic  systems  to  use  Ada  for  large  amounts  of  software.  Hence,  In  a  sense,  it  Is  a  test  case 
for  Ada.  Much,  but  not  all,  CSP  software  has  been  written  In  Ada.  Some  of  Ada's  good  points  are  that 
the  code  is  more  readable  than  most  languages,  the  programmers  tend  to  write  better-structured  code, 
debug  times  are  less  than  for  older  languages  (the  extra  constraint  checking  helps  to  find  more 
problems  at  compile  time),  and  It  is  especially  well-  suited  for  large  software  systems  written  by  a 
team  of  programmers.  The  design  time  tends  to  be  longer  with  Ada,  but  the  testing  time  Is  shorter, 
often  only  half  what  It  normally  takes.  The  language  Is  wordy  In  that  It  typically  requires  almost 
twice  the  number  of  Source  Lines  Of  Code  (SLOC)  that  other  languages  take,  but  this  extra  code  Is 
mostly  compile  time  information  that  does  not  produce  machine  code.  The  code  efficiency  of  the 
selected  Ada  compiler  for  the  embedded  1750A  controllers  is  about  the  same  as  that  for  good  JOVIAL  J73 
compilers  for  the  "sequential"  (non-tasking)  portion  of  the  language.  This  assumes  that  the  constraint 
checking  built  Into  the  language  (range.  Index,  type  checking)  has  been  suppressed  once  the  code  has 
been  debugged.  Constraint  checking  may  add  as  much  as  100*  to  the  code  size  and  run-time  or  as  little 
as  20*  depending  on  the  nature  of  the  code.  Ada  seems  best  suited  for  application  programs  and 
least-suited  for  operating  systems  or  control  programs  that  must  closely  manage  the  computer  resources. 
The  000  has  tightly  controlled  the  language  definition  and  compiler  certification  process  compared  to 
other  languages,  and  In  the  long  run,  this  should  be  a  great  benefit  for  achieving  comaonal Ity  and 
software  portability. 

An  obvious  difficulty,  especially  at  the  start  of  the  project.  In  using  Ada  was  the  Immaturity  of 
the  available  tools.  It  has  taken  a  long  time  to  achieve  usable  Ada  compiler  systems.  This  Is  due 
partly  to  Its  newness,  but  also  to  the  complexity  of  the  language  and  Its  novel  features.  The 
certification  process,  despite  Its  extensiveness,  has  not  guaranteed  that  the  compilers  will  produce 
correct  code;  It  tests  nothing  with  respect  to  efficiency.  Fortunately,  the  CSP  project  selected 
probably  the  best  Ada  compilers  available  at  that  time  and  so  the  negative  Impact  on  the  project  has 
been  minimized.  (Three  Ada  compilers  are  In  use  on  the  project:  the  DEC  VAX  compiler  being  used  for 
VAX-hosted  support  software,  the  Alsys  PC  AT  compiler  being  used  for  User  Console  software,  and  the  TLD 


6-7 


Systems,  LTD  VAX-hosted  cross-compiler  being  used  for  the  embedded  1750A  controllers.  Substantial 
resources  are  being  spent  to  Improve  the  TLD  toolset  for  CSP  use.)  The  CSP  project  began  with  the 
Intention  of  using  Ada  to  code  the  great  bulk  of  the  Local  Operating  System  (LOS).  Even  the  Ada 
parallel  processing  (tasking)  features  were  going  to  be  used  for  the  Internal  design  of  LOS.  But, 
unfortunately,  the  Ada  tasking  model  Is  a  poor  match  for  message-based  distributed  processing  systems. 
Too  many  rendezvous  (Ada's  basic  task  synchronization  feature)  were  needed  to  perform  key  functions 
which  could  be  done  with  half  as  many  simpler  primitives.  The  rendezvous  Itself  Is  quite  complex  and 
Inefficient.  (The  rendezvous  can  undoubtably  be  made  more  efficient  as  compilers  are  optimized,  but 
there  Is  an  Inherent  complexity  In  It  that  cannot  be  eliminated).  Ada  tends  to  remove  the  programmer 
from  the  machine  resources,  but  since  an  OS  manages  those  re-  sources,  use  of  Ada  tends  to  prevent  the 
programmer  from  accomplishing  his  task.  Following  an  evaluation  of  Ada  tasking,  the  LOS  was 
re-designed  to  use  conventional  tasking  primitives  written  In  MIL-STD-I7S0A  assembly  lang-  uage. 
"Sequential"  Ada  Is  used  to  code  portions  of  LOS.  Application  Command  Programs  (ACPs)  are  being 
written  in  Ada  and  these  programs  may  use  Ada  parallel  processing,  although  It  Is  discouraged  due  to 
Its  Inefficiency.  The  scope  of  an  Ada  program  Is  restricted  to  a  single  17S0A  processor;  coomunlcatlon 
between  processors  is  provided  by  LOS  services. 

The  CSP  project  has  made  extensive  use  of  chip,  module,  and  unit  level  simulations  in  order  to 
test  the  hardware  designs.  Even  more  simulation  use  would  have  been  beneficial.  Initially,  only  pure 
software  simulations  were  done.  These  are  practical  for  single  chip  logic  simulations  and  some 
multi-chip,  simulations,  but  they  are  too  slow  for  adequate  module  and  unit  simulations  at  the  logic 
(gate)  level.  The  largest  mainframe  computer  cannot  provide  reasonable  turn-around  times  for  these 
more  extensive  simulations.  Unfortunately ,  design  errors  often  exist  at  the  Interfaces  be-  tween 
components:  chlp-to-chlp  or  module-to-module,  since  they  are  usually  designed  by  different  people.  To 
provide  more  simulation  throughput,  IBM  acquired  a  logic  simulation  accelerator  from  ZYCAD  Corp.  This 
unit  can  be  attached  to  a  host  computer  and  used  as  a  peripheral  processor.  It  provides  several  orders 
of  magnitude  Improvement  In  typical  logic  simulation  times.  It  has  arrays  of  prograimable  logic 
elements  that  can  be  programed  to  model  the  circuit  at  the  gate  level  (modelling  at  the  transistor 
level  Is  also  possible).  The  logic  elements  operate  In  parallel  at  TTL-class  speeds  when  the 
simulation  Is  run.  Results  are  returned  to  the  host  computer.  The  user  can  monitor  his  circuit 
operation  very  conveniently.  Use  of  this  tool  significantly  Increased  the  amount  of  circuit  testing 
that  could  be  done  before  release  of  chips  and  modules  to  fabrication.  Significant  portions  of  the 
operating  system  were  run  on  the  simulation  before  the  hardware  was  available.  Development  of  complex 
"Application  Specific  ICs"  (ASICs)  for  use  In  highly  Integrated  systems  In  a  timely  manner  re-  quires 
the  use  of  such  a  simulation  tool  In  the  opinion  of  the  author. 

CSP  can  be  viewed  as  the  development  of  a  "coarse-grained"  parallel  processor  in  that  a  moderately 
large  number  of  processing  elements  and  memory  elements  can  be  connected  to  Its  Data  Network  and 
operated  In  parallel.  In  order  to  program  such  a  system  In  a  reasonable  length  of  time,  the  user  needs 
support  software  tools  to  make  his  job  slmp’er  than  was  the  case  for  previous  programmable  signal 
processors.  Development  of  these  tools  is  expensive  and  time-consuming,  but  necessary.  This  was 
recognized  at  the  beginning  of  the  project  and  planned  for.  A  rough  estimate  Is  that  CSP  will  include 
the  development  of  over  a  half  million  SLOC  before  the  project  is  completed.  Similarly,  the 
development  of  the  hardware  was  expensive.  A  dozen  large  semi-custom  ICs  and  a  half  dozen  gate  arrays 
were  developed  In  order  to  complete  the  core  design.  Considerable  effort  was  made  to  keep  the  ICs  as 
generic  as  possible  and  the  number  to  a  minimum,  but  how  to  do  this  can  often  be  best  seen  after  the 
design  Is  done.  It  seems  clear  from  the  CSP  experience,  that  It  order  for  parallel  processors  to  be 
affordable,  they  must  be  widely  applicable  and  they  must  be  relatively  technology  transparent  In  order 
to  amortize  the  development  costs  across  a  reasonable  set  of  applications.  It  is  felt  that  the  CSP 
System  can  meet  these  goals,  but  that  needs  to  be  demonstrated  In  actual  applications.  Perhaps  as  more 
Is  learned  about  how  to  design  parallel  processing  architectures,  designs  will  become  simpler  and  less 
expensive,  but  the  CSP  experience  suggests  that  useful  parallel  processors  will  remain  very  expensive 
to  develop  compared  to  serial  processors  for  the  1 mediate  future. 


Data  Network  Element  (ONE)  Modules  Required 


fDN  forts 
6 
8 
12 
18 
24 
30 


16-bit  Paths 

1 

2 

3 

4 

5 


32-bit  Paths 
1 
2 
4 
6 
8 
10 


Table  1.  Data  Network  (ON)  Configurations 


Core  Architecture  Modules 


ONE  -  Data  Network  Element 
ESU  -  Element  Supervisor  Unit 

FPPE  -  Floating  Point  Processing  Element 

GM  -  Global  Memory 

SI  -  Sensor 

V1750A  -  MIL-STD-1750A  Data  Processor,  emulated  with  ESUs) 

15538  -  MIL-STD-1553B  Input/Output  Module 


Support  Modules 

ICG  -  Timing  and  Control  Generator 

UCIF  -  User  Console  Interface 

IOT  -  I/O  Terminator  for  the  Pi-Bus 
PSs  -  Distributed  DC-DC  power  convertors 


Candidate  Additional  Modules 


VSPE  -  Fixed  Point  Vector  Signal  Processing  Element 
GPPE  -  General  Purpose  Processing  Element 
SEPE  -  Sort  Enhanced  Processing  Element 
8CPE  -  Bi-phase  Correlator  Processing  Element 
HS08  -  High  Speed  fiber  optic  Data  Bus  Interface 
GAPE  -  Gallium  Arsenside  Processing  Element 
FOSI  -  Fiber  Optic  Sensor  Interface 

Table  2.  CSP  Modules 
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k  SUMMARY 

1 

An  avionics  architecture  exploiting  high  speed,  high  density  VLSI  and  VHSIC  technology  by  repartitioning  the  traditional 
avionics  suite  requires  subsystem  interconnection  via  backbone  and  backplane  buses  and  networks  operating  at  data  rates  far 
exceeding  those  used  for  avionics  in  the  past  In  fact,  the  rates  are  high  enough  that  fiber  optics  is  the  only  interconnect  technology 
that  does  not  impose  substantial  size,  weight  and  life  cycle  cost  penalties  on  the  overall  system.  In  the  Pave  Pillar  architecture  the 
fiber  optic  multiplex  bus  for  command  and  control,  block  transfer,  and  flight  control  functions,  based  on  a  variation  of  the  IEEE  802.4 
and  802.2  token-passing  bus  protocol  for  the  physical  and  data  link  layers,  operates  at  50  Mbps.  A  number  of  specific 
implementations  have  emerged.  The  parallel  internal  (PI)  bus  protocol  ties  users  (data  processors)  together  in  the  backplane  and 
through  a  bus  interface  unit  to  the  multiplex  bus.  Ojjct  kinds  of  networks  are  used  to  serve  subsystems  connecting  video  terminals, 
sensors,  signal  processors,  etc. 

In  this  paper,  an  overview  of  the  multiplexed  high-speed  data  bus  and  parallel  internal  backplane  bus  designs  and  their 
interface  is  presented.  The  implementation  details  and  options  for  the  fiber  optic  network  which  supports  the  interconnection  of 
avionics  bus  interface  modules  in  different  physical  locations  are  discussed.  Passive  and  active  star-coupled  networks  are  compared 
and  conclusions  drawn.  The  state  of  the  art  in  packaging  of  the  avionics  bus  interface  and  related  line  replaceable  modules  is 
illustrated. 


I.  INTRODUCTION 

An  advanced  avionics  architechture  gaining  widespread  acceptance  among  designers  of  future  aircraft,  and  finding 
applications  in  spacecraft  and  ships,  evolved  out  of  study  programs  sponsored  by  the  U.S.  Air  Force.  The  Pave  Pillar  architecture, 
shown  in  Figure  1 ,  capitalizes  on  the  latest  advances  in  electronic  technology,  such  as  Very  Large  Scale  Integration  (VLSI)  and  Very 
High  Speed  Integrated  Circuits  (VHSIC),  and  incorporates  common  elements  among  subsystems  thereby  offering  life  cycle  cost 
benefits  and  unprecedented  flexibiUty { 1  ] .  A  new  partitioning  philosophy  of  loosely-coupled  distributed  processors  is  required  to 
achieve  these  goals  forcing  subsystem  elements  to  be  interconnected  with  high  speed,  wide  bandwidth  data  links.  Modularity  of  the 
avionics  components  naturally  follows.  Distributed  data  bases  add  to  the  overall  processing  flexibility.  Furthermore,  the  parallel  data 
and  signal  processor  interconnects  must  operate  at  high  rates  to  keep  up  with  the  enormous  processing  capacity  now  possible. 


i 

I 


In  the  architecture  shown  in  Figure  1,  the  mission  avionics  multiplex,  block  transfer,  and  vehicle  management  buses  all  use 
common  components  (to  a  certain  point)  and  operate  at  a  serial  data  rate  of  50  Megabits  per  second  (Mbps).  The  sensor  area  network 
must  have  a  throughput  approaching  1  Gigabit  per  second  (Gbps).  The  video  bus,  when  implemented  tn  a  wideband  analog  format, 
requires  a  bandwidth  of  nearly  1  Gigahertz  (GHz).  From  a  size,  weight,  and  life  cycle  cost  standpoint,  it  can  readily  be  shown  that  a 
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fiber  optic  implementation  of  these  buses  and  networks  has  significant  benefits.  In  fact,  from  an  electromagnetic  interference  and 
compatibility  standpoint,  this  architecture  may  not  be  realizable  in  some  weapons  systems,  especially  tactical  fighter  aircraft  with  size 
and  weight  constraints,  unless  fiber  optics  is  used. 

In  this  paper,  we  will  focus  on  the  details  of  the  fiber  optic  multiplex  high  speed  data  bus  which  ties  subsystems  together, 
the  parallel  internal  or  backplane  bus  which  ties  groups  of  subsystem  users  together,  and  the  gateway  which  ties  the  high  speed  data 
bus  and  parallel  internal  buses  together.  The  component  which  houses  the  principal  elements  of  these  buses  is  referred  to  as  the  bus 
interface  unit  or  avionics  bus  interface  (ABI).  (We  will  use  the  latter  term  in  this  paper.)  It  translates  the  "languages"  of  the  two  buses 
in  the  most  efficient,  economical  manner  possible.  Associated  with  each  bus  is  a  specific  protocol  that  allows  all  the  terminals  on  the 
fiber  optic  network  to  communicate  effectively  and  all  users  and  their  processors  to  send  and  receive  data  in  a  standard  format  for  cost, 
performance,  and  commonality  benefits.  We  will  first  look  at  the  overall  structure  of  the  ABI.  Then,  we  will  review  the  operation  of 
the  bus  protocols  and  how  the  standards  defining  them  evolved.  The  multiplex  high  speed  data  bus  will  be  considered  in  detail  with 
emphasis  on  the  physical  layer  and  physical  medium  dependent  components  of  the  network  and  the  fiber  optic  technology  needed  to 
realize  a  complete  system  with  users. 

2.  THE  AVIONICS  BUS  INTERFACE  ARCHITECTURE 

A  block  diagram  of  a  typical  ABI,  showing  the  major  components  and  external  and  internal  interfaces,  is  shown  in  Figure  2. 
The  avionics  bus  interface  module  provides  the  interface  between  dual  parallel  internal  (PI)  buses  and  a  high  speed  data  bus  (HSDB). 
The  PI -bus  is  a  16-bit  parallel  distributed-control  message-transfer  network.  Any  module  connected  to  this  bus  can  request  access  to 
it  and  conduct  block  reads  and  writes.  In  the  write  mode,  multiple  modules  can  be  addressed  simultaneously.  The  ABI  receives 
messages  addressed  to  it  on  the  Pi-buses,  interprets  the  messages,  gains  control  of  the  HSDB,  and  initiates  a  message  transfer  on  it. 
The  ABI  also  receives  messages  addressed  to  it  on  the  HSDB,  interprets  the  messages,  vies  for  the  PI -bus,  and  initiates  a  message  cm 
it.  The  ABI,  therefore,  consists  of  an  intelligent  store-and-forward  gateway  between  the  Pi-buses  and  the  HSDB.  A 
MIL-STD-1750A  (1750A)  processor  can  be  used  to  control  and  manage  the  gateway  between  the  HSDB  and  Pi-buses.  Note  that  the 
ABI  has  two  totally-independent  interfaces  to  the  Pi-buses,  one  or  more  interfaces  to  the  HSDB,  and  one  to  a  test  and  maintenance 
(TM)  bus.  Added  redundancy,  if  necessary,  is  provided  by  multiple  ABIs. 

3.  THE  HIGH  SPEED  DATA  BUS  PROTOCOL 

Ii.  principle,  the  high  speed  data  bus  portion  of  the  ABI  is  partitioned  in  a  standard  manner  according  to  the  International 
Organization  for  Standards  (ISO)  Open  Systems  Interconnection  format[2).  The  token-passing  protocol  for  the  machine  evolved  from 
the  Institute  of  Electrical  and  Electronic  Engineers  (IEEE,  USA)  Standard  802(3).  Only  the  first  two  layers  of  the  OSI  format  defined 
by  IEEE-STD-802.2  and  802.4  are  used  in  the  HSDB  ABI.  Figure  3  shows  the  relationship  of  the  OSI  layer  terminology  and  various 
IEEE-STD-802  elements.  Although  the  relation  shown  is  fixed,  numerous  variations  on  this  standard  have  evolved  to  meet  the 
specific  and  more  restrictive  needs  of  the  bus  for  avionics  applications.  This  includes  the  Society  of  Automotive  Engineers  (SAE) 
draft  standard  AS4074.1[4],  the  protocol  specified  in  the  VHSIC  Avionics  Modular  Processor  (VAMP)  program  sponsored  by  the 
U.S.  Air  Force  [5],  and  the  protocol  defined  for  the  Lockheed  Advanced  Tactical  Fighter  (ATF)  program(6],  which  are  all 
interoperable,  and  several  others  [7,8,9]  which  are  not. 


A  brief  discussion  of  the  SAE  data  bus  and  protocol  follows(4].  It  consists  of  a  set  of  stations  broadcast -connected  on  the 
transmission  medium-that  is,  each  station  which  transmits  is  heard  by  all  of  the  other  stations.  A  transmission  is  accepted  based  on 
physical  or  logical  addressing  mechanisms.  Access  to  the  fiber  optic  transmission  medium  is  controlled  by  a  token  which  is  continually 
passed  around  a  logical  ring  formed  out  of  all  the  stations.  A  station  receiving  the  token  gains  the  right  to  use  the  transmission 
medium  for  a  certain  amount  of  time.  The  amount  depends  upon  the  value  of  the  token  holding  timer  (THT),  used  for  all  messages  of 
priority  0  (high),  as  well  as  the  residual  value  of  the  token  rotation  timers  (TRTs),  one  for  each  decreasing  priority  from  1  to  3.The 
amount  of  time  is  always  less  than  or  equal  to  a  predetermined  maximum  value  based  on  circumstances  of  die  bus  traffic.  When  this 
amount  of  time  has  expired,  or  the  station  has  sent  all  of  its  messages,  then  the  station  forwards  the  token  to  the  next  member  of  the 
logical  ring. 

Low  latency  for  high  priority  messages  is  assured  by  the  use  of  message  priority  TRTs.  A  station  which  has  a  message  at 
the  highest  priority  (0)  always  sends  that  message  when  it  receives  the  token.  A  station  which  has  a  lower  priority  message  sends  it  if 
the  token  rotation  timer  associated  with  that  priority  level  has  not  expired.  Otherwise,  the  station  must  forward  the  token  to  its 
successor.  In  this  way  the  token-passing  bus  users  defer  to  higher  priority  traffic  when  the  traffic  load  becomes  heavy. 
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Figure  3.  IEEE  802  Standardization  Project  Standards  Structure. 

Station  failures  are  handled  by  the  station  immediately  preceding  the  failed  station  in  the  logical  ring  sequence.  The  station 
passing  the  token  verfies  that  there  is  bus  activity.  After  two  consecutive  attempts  at  passing  the  token,  the  station  automatically 
increments  the  destination  address  in  the  token  and  tries  again.  This  incremental  bridging  continues  until  the  station  finds  a  successor 
or  the  destination  address  wraps  around  and  matches  the  local  station  address  at  which  time  the  station  shall  cease  its  attempts  to  find  a 
successor.  Stations  are  allowed  admittance  to  the  logical  ring  on  a  periodic  basis.  Each  station  has  a  ring  admittance  timer  (RAT). 
When  this  timer  expires  and  there  is  a  gap  between  the  local  station's  address  and  that  of  its  successor,  the  token  is  passed  to  the 
sequential  address  following  that  of  the  local  station.  The  normal  token  passing  rules  are  then  applied.  Therefore,  if  any  of  the 
stations  in  the  gap  desire  admittance  they  shall  be  granted  an  opportunity  during  this  tune. 

Intializahon  of  the  logical  ring  occurs  after  the  token  is  lost  or  on  power  up.  Each  station  which  powers  up  and  completes  its 
own  internal  diagnostic  and  startup  procedures  activates  a  bus  activity  time  (BAT).  If  the  station  hears  any  valid  transmission  it  resets 
this  timer.  This  indicates  that  some  portion  of  the  logical  ring  is  active  and  the  station  defers  any  activity.  The  station  may  receive  a 
valid  token  addressed  to  it  because  the  ring  admittance  timer  of  a  station  numerically  preceding  it  in  the  logical  ring  has  expired.  In 
this  case,  the  station  begins  to  hunt  for  a  successor  using  the  normal  token-passing  rules.  If  the  bus  activity  timer  expires,  the  station 
attempts  to  gain  control  of  the  token.  It  transmits  a  frame  whose  length  is  determined  by  the  station  address  and  the  physical  length  of 
the  bus.  After  completing  its  transmission  and  waiting  for  a  time  based  upon  bus  length  it  listens.  If  the  station  hears  any  other 
transmission,  it  has  lost  the  claiming  process  and  waits  for  the  token.  If  the  station  hears  nothing  it  assumes  that  it  has  won  the  token 
and  begins  to  hunt  for  a  successor.  In  this  case  the  normal  token-passing  rules  apply. 

System  monitoring  is  provided  by  watching  the  passage  of  the  token  throughout  the  logical  ring  and  station  management 
status  messages.  The  user  is  notified  whenever  a  change  has  occurred  or  when  commanded  to  do  so.  Station  management  status 
messages  are  utilized  by  a  station  to  report  specific,  non-fatal  problems  such  as  a  receiver  or  transmitter  failure. 

Because  the  selection  of  physical  medium  dependent  (PMD)  components  strongly  depends  on  the  characteristics  of  the 
physical  layer  protocol,  a  description  of  the  line  states  and  symbol  set  used  is  needed.  There  arc  2  line  states,  quiet  (or  idle)  and  busy, 
and  3  kinds  of  symbols,  control,  data,  and  violation.  When  there  is  no  bus  activity,  the  transmission  medium  is  said  to  be  quiet.  It  is 
busy  if  a  signal  is  being  transmitted  on  the  physical  medium.  A  signal  is  defined  by  a  range  in  the  time  rate  at  which  transitions  must 
occur  according  to  the  encoding  scheme  chosen.  For  example,  a  50  Mbps/100  Mbaud  Manchester-encoded  implementation  (the 
method  for  the  Pave  Pillar  HSDB  and  many  others)  must  have  transitions  every  10,  15,  or  20  nanoseconds  (ns).  (This  includes 
allowed  illegal  Manchester  symbols.)  So,  there  must  always  be  at  least  3  signal  transitions  in  any  4  consecutive  data  bit  slots  to  be 
considered  busy.  This  is  important  because  the  receiver  and  clock  recovery  unit  may  be  sensitive  to  the  transition  density  of  the 
signal. 

The  structure  of  every  frame  transmitted  must  conform  to  that  shown  in  Figure  4.  Frames  may  be  concatenated  up  to  the 
limit  established.  In  addition,  every  transmission  is  preceded  by  a  preamble  used  for  receiver  synchronization.  This  is  the  first  of  the 
control  symbols.  The  length  of  the  preamble,  which  depends  on  a  myriad  of  factors,  is  given  in  the  "slash  sheet"  to  the  standard  or  in 
a  specification  for  an  intended  implementation.  A  16  bit-time  preamble  is  sufficient  for  any  Manchester-encoded  HSDB  in  a  passive 
star-coupled  topology.  It  is  always  a  maximum  transition  density  code;  thus  for  the  Pave  Pillar  HSDB,  there  is  a  transition  every  10 
ns  up  to  320  ns  (16  bit  times).  The  start  and  end  delimiters  (SD,ED)  are  the  other  control  symbols.  They  are  unique  and  define  the 
beginning  and  end  of  the  protocol  data  unit  (PDU).  In  Manchester-encoded  implementations,  the  SD  and  ED  must  be  "illegal"  to  be 
unique;  that  is  transitions  occur  15  ns  apart  instead  of  every  10  or  20  ns  for  "legal"  Manchester  code  in  a  50  Mbps  HSDB. 
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Figure  4.  Overall  Front  Structure  of  a  Transmission. 
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The  PDU  carries  the  data  symbols  each  conveying  one  or  more  binary  digits  (bits).  In  Manchester-encoded  systems,  only 
legal  (valid)  Manchester  symbols  are  allowed.  All  "ones"  or  "zeros"  of  data  give  the  highest  symbol  transition  density,  the  same  as 
the  preamble.  Alternating  "ones"  and  "zeros"  give  the  lowest  symbol  transition  density,  one  each  20  ns  in  a  50  Mbps  HSDB,  Any 
detected  activity  which  does  not  conform  to  prescribed  control  or  data  symbols  is  a  violation  symbol.  The  resulting  bit  errors  arc 
grounds  for  rejection  of  a  frame. 

One  other  parameter  of  importance  to  the  design  of  the  fiber  optic  components  is  the  length  of  time  between  consecutive 
transmissions  by  different  transmitters.  It  must  be  such  that  a  system  minimum  intertransmission  gap  time  (1GT)  is  guaranteed  at  any 
given  receiver's  input.  The  optical  receiver  must  perform  as  specified  (usually  by  bit  error  rate  on  data  bits)  when  the  minimum  IGT 
occurs  under  worst  case  operating  conditions  where  the  full  intertransmission  dynamic  range  (IDR)  exists  between  the  end  bit  of  one 
message  and  the  start  bit  (preamble)  ctf  the  next  message.  With  this  information,  the  fiber  optic  avionics  bus  interface  and  interconnect 
components  can  be  specified  and  a  complete  HSDB  interface  designed  Before  we  do  that,  though,  a  brief  look  at  the  rest  of  the  ABI 
components  will  be  taken. 

4.  THE  PARALLEL  INTERNAL  (BACKPLANE)  BUS  PROTOCOL 

The  avionics  bus  interface  module  is  one  of  many  housed  in  an  integrated  rack  serving  a  variety  of  users  or  hosts.  They  are 
all  connected  by  a  parallel  internal  (PI)  bus  which  resides  in  the  backplane  of  the  rack.  The  HSDB  is  used  to  tie  together  various  racks 
which  make  up  the  avionics  suite.  Figure  5  shows  a  typical  configuration  including  the  Pi-bus  interfaces  and  the  basic  internal 
structure  of  the  ABI.  Here  is  a  brief  description  of  its  origins  and  how  it  works. 
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The  parallel  interface  bus  evolved  from  the  work  of  three  VHSIC  contractors  and  the  U.S.  Air  Force!  10].  The  Pi-bus 
consists  of  VHSIC  devices  connected  at  the  backplane  through  transceivers  to  form  a  12.5  MHz  bus  with  a  16  (or  32)  bit  path 
width(  11],  Unlike  the  token-passing  HSDB,  it  is  a  contention  bus  in  which  each  user  or  host  connected  including  the  ABI  must  vie 
for  the  right  to  acquire  temporary  bus  mastership.  Once  a  host  has  obtained  bus  mastership  it  can  send  data  to,  or  receive  data  from, 
another  host.  To  accomplish  this  the  bus  master  sends  header  information  over  the  bus  followed  by  data.  The  source  host  commands 
the  pi-bus  "Bus  Interface  Unit"  (BIU)  (Figure  2)  through  a  Communication  Control  Block  (CCB)  which  is  accessed  through  a  1750A 
XIO  sequence  or  equivalent.  This  sequence  (Figure  6)  provides  the  BIU  with  two  CCB  control  words.  The  first  (Control  Word  1 ) 
contains  the  logical  Pi-bus  priority  and  the  upper  eight  bits  of  the  address  of  the  CCB  chain.  The  second  (Control  Word  2),  provides 
the  lower  16  bits  of  the  CCB  chain.  Upon  the  reception  of  CCB  Control  Word  2  the  BIU  begins  processing  the  CCB  chain.  This 
chain  consists  of  control  data,  the  module's  data  buffer  address,  and  the  lour  Pi-bus  header  words  (Figure  7).  The  first  of  these 
header  words  designated  "Header  Word  A"  contains  a  PI  bus  physical  address,  or  the  Pi-bus  broadcast  address.  The  second  header 
word  (B)  contains  a  value  indicating  the  number  of  words  to  be  transferred.  The  third  header  word  (CO)  contains  a  label,  and  the 
fourth  (Cl)  contains  an  offset. 

Header  words  CO  (HWCO)  and  Cl  (HWC1)  are  used  to  address  the  ABI's  memory  In  the  first  transmission  to  a  ABI  the 
label  (HWCO)  represents  the  ABIs  starting  address  and  HWC1  contains  all  zeros.  If  for  some  reason  the  message  is  suspended,  the 
source  host  must  send  a  resume-sequence  header  prior  to  sending  the  rest  of  the  message.  The  resume-sequence  HWCO  will  contain 
the  same  label  and  the  value  of  HWC1  will  represent  the  number  of  words  successfully  transferred  before  suspension.  Upon  receipt 
of  an  unsolicited  Pi-bus  message  the  ABI's  BIU  will  test  the  label  and,  if  the  label  is  contained  within  its  label  table  and  is  active, 
accept  the  message.  The  ABI  will  then  store  the  data  in  its  interface  memory  using  the  value  obtained  from  the  label  table  for  starting 
address  (Figure  8).  When  the  entire  message  has  been  received,  the  BIU,  if  requesied,  will  notify  the  ABI's  1750A  processor  via  a 
"Program  Control  Interrupt"  (PCI).  Upon  receipt  of  the  PCI  the  ABI  will  begin  processing  the  message  and  will  transmit  the  message 
across  the  HSDB  subject  to  instructions  received  from  the  host  device  and  the  HSDB  protocol. 
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Figure  6.  Control  Words  Initiate  PI -Bus  Operation. 


HEADER  WORD  A  (HWA) 
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Figure  7.  PI -Bus  Header  Words. 


Recall  that  the  Pi-bus  addressing  scheme  uses  an  address  (or  ID)  and  a  label  to  communicate  across  the  Pi-bus.  The  address 
is  an  ABI's  physical,  logical,  or  broadcast  address.  The  user  can  thus  address  a  specific  physical  ABI  or  can  use  logical  addressing 
(which  permits  various  addressing  techniques  such  as  group  addressing).  However,  the  user  can  take  advantage  of  the  broadcast 
address  and  labels  to  develop  an  architecture  based  upon  the  powerful  technique  of  global  addressing.  In  this  case  each  process 
and/or  function  in  the  avionics  suite  has  a  unique  address.  Any  process  or  function  needing  to  communicate  with  another  process  or 
function  need  not  be  concerned  with  the  physical  address  or  location  of  the  destination  since  all  communication  would  be  through  the 
label.  This  has  significant  advantages  during  reconfiguration  due  to  changing  mission  requirements,  or  possibly  if  there  is  an 
equipment  failure  in  that  it  is  only  necessary  to  change  a  single  label  at  a  single  location  to  accomplish  reconfiguration.  In  contrast,  if 
physical  addressing  were  used  for  a  case  in  which  a  source  process  was  transmitting  to  many  other  processes,  changing  and  verifying 
all  of  the  destination  addresses  could  be  a  formidable  task  increasing  the  probability  of  error. 


Figure  8.  PI -Bus  Label  Derives  Sinning  Address. 
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5.  THE  FIBER  OPHC  HIGH  SPEED  DATA  BUS  COMPONENTS 

In  the  discussion  which  follows,  we  are  concerned  chiefly  with  the  fiber  optic  transmitter  and  receiver  circuits  of  the  ABj, 
shown  in  Figures  2  and  5.  The  design  of  these  components  is  determined  by  characteristics  of  the  HSDB  protocol  machine, 
requirements  of  the  platform  in  which  the  HSDB  resides  (such  as  an  aircraft),  and  component  and  configuration  options  for  the  HSDB 
network  external  to  the  ABIs.  A  basic  requirement  of  the  Pave  Pillar  HSDB  is  to  serve  up  to  64  ABIs.  In  a  high  performance  aircraft 
which  operates  in  an  environment  with  many  variables,  the  best  design  approach  is  not  obvious. 

A  convenient  point  of  departure  is  to  trade-off  configuration  or  topology  options  and  active  versus  passive  implementations. 
Active  here  implies  the  use  of  devices  to  amplify  or  regenerate  a  signal  along  the  path  between  transmitter  and  receiver.  Passive 
topologies  have  no  "gain"  elements  between  source  and  sink.  In  general,  the  complexity  of  the  added  active  components  can  be  traded 
against  the  complexity  of  the  terminal  transmitters  and  receivers,  and  the  risk,  reliability,  survivability,  maintainability,  etc.  of  the  two 
approaches.  Many  studies  have  shown  that  a  passive  star-coupled  bus  has  distinct  advantages  over  an  active  implementation  in  these 
respects.  Despite  the  challenge  a  passive  topology  presents,  the  recent  development  and  availability  of  several  key  components,  and 
the  wise  choice  of  certain  design  options,  makes  this  approach  feasible  ( 12].  In  this  paper,  both  passive  and  active  implementations 
will  be  considered.  We  will  first  consider  passive  star-coupled  networks. 

The  basic  passive  star-coupled  fiber  optic  high  speed  data  bus  has  a  single  access  coupler,  the  so-called  star  coupler,  at  the 
center  of  the  system.  A  schematic  representation  of  this  network  is  shown  in  Figure  9.  It  generally  has  the  same  number  of  inputs  and 
outputs.  A  signal  coming  in  on  any  input  is  distributed  by  the  device  to  each  and  every  output  in  approximately  equal  amounts.  If 
there  are  signals  on  two  or  mere  inputs  at  any  one  time,  they  will  be  mixed  optically  and  then  distributed  among  all  the  outputs.  Thus, 
to  keep  multiple  signals  Cat  the  same  optical  wavelength)  from  interfering,  there  must  be  transmissions  from  only  one  optical  source 
(ABI)  at  any  given  time.  Since  all  receivers  hear  all  transmissions,  this  topology  is  sometimes  referred  to  as  a  broadcast  network. 
There  are  several  viable  passive  access  coupler  fabrication  technologies,  but  the  one  which  is  the  roost  popular  at  this  time  and  has 
undergone  the  most  successful  environmental  testing  is  known  as  the  fused  biconical- taper  coupler!  13).  This  discussion  is  based  on 
data  for  a  star  coupler  of  that  kind.  The  remainder  of  the  network  consists  of  die  ABI  transmitters,  up  to  64,  connected  to  the  access 
coupler  inputs  with  fiber  optic  cable  and  optical  connectors  as  required;  and  up  to  64  ABI  receivers  connected  in  the  same  manner  to 
the  coupler's  outputs. 
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Figure  9.  A  Star-Coupled  Network. 

A  link  power  budget  analysis  approach  to  network  design  is  usually  used.  Beginning  with  the  transmitter,  the  optical  power 
coupled  into  a  fiber  is  tracked  through  all  the  components  in  the  network  to  the  receiver  input.  After  calculating  all  the  system  factors, 
the  receiver  performance  requirements  are  specified  and  a  separate  investigation  of  the  optimum  approach  to  meeting  these 
requirements  is  necessary.  It  is  not  until  this  point  that  the  multitude  of  receiver  design  options,  encoding  and  decoding  techniques, 
preamble  requirements,  clock  recovery  issues,  imertransmission  gap  times,  and  so  on,  begin  to  enter  the  picture.  This  activity  is  a 
major  portion  of  the  whole  design  effort,  yet  is  quite  sensitive  to  the  interconnect  component  requirements  and  assumptions. 

To  insure  an  optimum  system  design,  factors  such  as  achievable  transmitter  power,  thermal  effects  and  compensation,  and 
end  of  life  criteria;  connector  qualities  and  kinds,  their  and  cable  intrinsic  and  induced  loss  and  distortion  contributions  and  the  fiber 
size  dependence;  and  access  coupler  splitting  and  excess  loss,  port- to- port  variations,  and  environmental  performance  expectations 
must  all  be  taken  into  account  The  weak,  distorted  optical  signal  at  the  ABI  receiver  input  must  be  reconstructed  into  a  reproduction 
of  the  transmitted  electrical  signal,  a  clock  waveform  must  be  extracted  and  synchronized  to  the  data,  and  both  presented  to  the  next 
layer  of  activity,  all  done  with  the  fewest  number  of  errors  possible  since  error  correction  is  a  process  not  available  in  this  bus,  only 
error  detection  (the  cyclic  redundancy  check). 

6.  THE  TRANSMITTER  OPTICAL  SOURCE 

The  difference  between  available  transmitter  power  and  receiver  sensitivity  is  the  link  power  budget  The  difference  between 
the  actual  power  delivered  to  the  receiver  input  and  the  receiver's  sensitivity  is  the  link  margin.  Clearly,  to  obtain  die  largest  possible 
link  margin,  one  should  choose  the  largest  possible  transmitter  power.  For  fiber  optic  systems  in  general,  that  is  achieved  with  the 
use  of  injection  laser  diode  (ILD)  devices;  however  their  use  is  not  recommended  here,  not  so  much  because  they  require  large  dc 
power  for  operation,  but  because  they  require  more  time  to  turn  on  from  a  totally  off  (unbiased)  state  than  is  available  in  this  system. 
The  broadcast  nature  of  this  network  does  not  permit  unmodulated  carrier  transmission  by  multiple  sources  in  the  background.  So  it 
is  necessary  to  employ  light -emitting  diodes  (LEDs)  for  this  system. 

Next,  consider  the  LED-to-opticai  fiber  interface.  Since  the  source  size  is  small,  and  surface-emitters  (SLEDs)  have  a  nearly 
Lambertian  (cosine  law)  radiation  pattern,  any  effort  to  concentrate  all  the  energy  on  the  end  of  an  optical  fiber  will  have  limited 
success.  (Edge-emitters  have  some  of  the  same  problems  as  ILDs  and  are  not  as  attractive.)  A  simple  way  of  collecting  the  maximum 
amount  is  to  use  the  largest  diameter  fiber  that  is  practical.  More  will  be  said  about  fibers  later,  but  fiber  core  diameters  up  to  200 
micrometers  are  worth  considering.  Rugged  avionics  cables  incorporating  fibers  up  to  this  size  have  been  fabricated  and  are  currently 
flying  with  success  on  commercial  and  military  aircraft  in  this  country  and  abroad.  The  possibility  for  even  larger  fibers  in  the  future 
exists. 


The  task  of  selecting  a  prototype  LED  is  particularly  easy  because  high  radiance  devices  in  hermetic  packages  with  100  and 
200  micrometer  core  optical  fibers  pigtailed  to  the  device  are  currently  available.  They  have  been  used  in  many  programs  and  proven 
to  have  the  reliability  needed  for  this  application.  One  supplier  provides  devices  with  room  temperature  (25®C)  peak  coupled  power 
of  -1.25  dBm  and  +  2  dBm,  minimum,  for  100  and  200  micrometer  core  fiber,  respectively.  Typical  power  levels  are  1  dB  greater 
[14].  The  rise  and  fall  times  of  these  devices  support  a  lOOOMbaod  system.  The  final  available  transmitter  power  will  be  less  than 
these  figures,  of  course,  because  they  must  be  derated  to  account  for  a  variety  of  factors  discussed  next 
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The  most  significant  factor  is  operating  temperature.  The  modules  housing  the  transmitter  will  be  actively  cooled,  but  a 
junction  temperature  of  105°C  can  be  expected  sometime  during  the  device  Life.  In  a  very  cold  ambient  environment,  considerably 
lower  junction  temperatures  will  exist.  Since  the  LED's  power  output  varies  with  temperature,  it  is  essential  that  the  output  be  actively 
compensated.  This  requires  the  maximum  output  power  to  be  reduced  by  about  3  dB  to  accommodate  the  80°C  rise  above  room 
temperature  which  may  be  encountered.  This  preserves  die  reliability  desired  for  the  device.  Next,  it  must  be  recognized  that  the 
output  power  will  decrease  throughout  the  life  of  the  device.  An  accepted  end-of-life  criterion  for  power  is  3  dB  below  the  initial  level 
which  could  occur  as  soon  as  20  or  30  yean  after  installation  assuming  continuous  operation.  So  for,  6  dB  of  derating  has  been 
applied.  There  will  be  a  spread  in  optical  power  among  new  devices  which  will  be  assumed  here  to  be  3  dB.  This  value  is  wide 
enough  that  there  should  not  be  any  significant  cost  penalty.  Noting  that  a  near  end-of-life  transmitter  and  a  new  one  could  both  be  in 
the  system  at  the  same  time,  there  could  be  a  swing  of  6  dB  in  acceptable  output  power  from  temperature  compensated  transmitters. 
(This  would  increase  to  perhaps  10  dB  if  uncompensated.) 

Table  1  summarizes  the  above  discussion  for  the  prototype  LEDs  with  100  and  200  micrometer  optical  fibers.  In  both  cases, 
it  can  be  shown  that  the  passive  star-coupled  high  speed  data  bus  is  viable  with  the  correct  receiver  design.  Because  of  the  increased 
available  power,  and  other  reasons  to  be  men  booed,  it  is  preferable  to  use  a  200  micrometer  core  fiber  from  the  optical  source. 
However,  until  it  is  necessary  to  know  how  much  power  is  incident  on  the  receiver,  it  is  not  necessary  to  make  the  choice. 

Table  1.  Available  Transmit  &  Power. 


Fitw  Cote  Size  (um) 

100 

200  . 

Opted  Powar.  dBm 

Mn. 

Mn 

Mn. 

Mn. 

At  Room  Tampara&jri 

-1.25 

*225 

♦2 

*5 

Altar  Tamp.  Companution 

-425 

•1.25 

-1 

♦ 2 

At  and-oMfa 

-7.25 

-4.25 

■4 

-1 

09-418303 


7.  THE  OPTICAL  CONNECTORS 

•  Defining  the  characteristics  of  the  optical  connections  is  one  of  the  most  difficult  parts  of  the  data  bus  design  because  the 
physical  attributes  of  the  intended  installation  are  almost  always  poorly  defined.  The  problem  is  significant  for  fiber  optics  because, 
unlike  conventional  wire,  the  system  performance  is  sensitive  to  the  kinds  of  connections  and  the  number  of  them.  Fortunately, 
several  physical  characteristics  of  the  avionics  packaging  plan  are  well  enough  defined  that  some  of  the  uncertainty  about  the 
interconnection  issue  can  be  removed.  The  nature  of  the  application  suggests  that  most  of  the  connections  will  have  to  be  demountable 
to  support  maintainabilty  and  availability  requirements.  Quasi-permanent  or  totally  permanent  splices  are  reserved  for  a  few  specific 
places.  The  use  of  fusion  splices  (fusion  by  electric  arc)  may  be  limited  to  harness  fabrication  in  the  wire  shop  or  on  the  assembly  line 
due  to  safety  considerations.  Other  splicing  techniques  will  have  to  offer  substantial  advantages  over  demountable  connections  to 
justify  their  use.  In  the  present  packaging  scheme  for  future  avionics,  there  will  have  to  be  two  serial  disconnects  associated  with  each 
transmitter  and  receiver:  one  on  the  AB1  module  housing  them  and  one  at  the  “rack"  housing  a  number  of  the  ABI  modules.  This  is, 
at  least,  the  cleanest  configuration.  There  will  also  be  several  "bulkhead”  disconnections  at  structural  supports  or  airframe  splices.  An 
allowance  for  two  of  them  will  be  made  here  although  more  are  possible  if  necessary.  Finally,  there  are  the  input  and  output 
connectors  at  the  access  coupler.  Figure  10  illustrates  an  installation  concept  based  on  the  above  discussion. 


Figure  10.  Typical  Aircraft  Installation. 

Assigning  a  reasonable  value  for  insertion  loss  for  these  connectors  is  a  difficult  task.  It  is  important  to  consider  both  the 
intrinsic  connector  loss  and  the  effect  that  time  has  on  performance.  One  worst  case  scenario  is  to  pick  some  nominal  value  for 
insertion  loss,  add  several  decibels  to  each  for  degradation,  and  then  multiply  that  by  the  number  of  connectors  in  the  path  from  a 
transmitter  to  receiver.  With  recent  improvements  in  connector  technology  resulting  in  lower  intrinsic  losses,  consistency  in  loss 
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from  mating  to  mating,  and  improved  alignment  mechanisms,  it  simply  is  not  necessary  to  take  an  extreme  view  of  the  connector  loss 
situation.  Single  channel  connectors  with  losses  consistently  below  1  dB  for  hundreds  of  matings  and  repeatability  in  the  0.1  dB 
range  ate  now  available  dam  multiple  suppliers.  A  worst  case  in  which  ail  connectors  have  high  loss  simultaneously  is  probably  not  a 
reasonable  one,  especially  when  consistency  in  performance  is  taken  into  account  Furthermore,  after  a  maintenance  action,  a  good 
optical  connection  can  be  verified  with  the  system's  built-in-test  circuitry.  Once  the  connection  is  made,  dirt  and  other  foreign  objects 
will  be  virtually  unable  to  enter  the  connector  space  in  any  reasonable  design.  Finally,  there  are  connector  tenmnii  designs  now  being 
fielded  which  use  lenses  snd  still  retain  small  diameters.  They  have  the  advantage  of  being  much  less  sensitive  to  small  obstructions 
in  the  space  between  the  connector  halves  because  of  their  relatively  large  optical  cross-  sectional  area.  This  property  offers  an 
advantage  over  connector  tenmnii  in  which  the  aids  of  the  fibers  face  each  other  directly. 

So,  the  following  connector  loss  assignments  ate  made.  For  six  connecrors  at  the  modules,  racks,  and  bulkheads,  a  total 
worst  case  loss  of  6  dB  is  assessed.  Thus  there  might  be  four  0.5  dB  connectors,  a  1  dB  connector,  and  one  3  dB  connector  which 
has  suffered  s  difficulty,  but  not  one  requiring  maintenance  action.  Any  other  assignment  can  be  hypothesized,  of  course.  For  the 
two  connecsors  sr  the  star  coupler,  a  total  worn  case  loss  of  6  dB  is  assessed.  This  is  done  because  t  different  type  of  connector  may 
be  required  here  to  accommodate  a  large  number  of  connections  (64).  A  greater  degree  of  freedom  in  losses  is  s  prudent  decision  for 
this  connector.  Collectively,  a  worst  case  loss  of  12  dB  is  assigned  to  the  eight  connectors  allowed  between  any  transmitter  and 
receiver  in  this  network.  The  lowest  loss  (best  case)  will  be  found  for  those  paths  which  do  not  have  bulkhead  connectors,  and  which 
have  optimum  connections.  For  analysis  purposes,  sn  assignment  of  4  dB  is  made  for  this  case. 


8.  THE  OPTICAL  FIBER  AND  CABLE 

The  fiber  optic  cable  loss  is  divided  into  intrinsic  and  externally  induced  contributions.  Scattering  and  absorption  are 
responf  ible  for  most  of  the  intrinsic  loss  which  is  generally  very  low  (a  few  dB  per  kilometer)  for  modem  optical  fibers.  The  cabling 
and  jacketing  process  is  responsible  for  increasing  microbending  loss,  but  can  be  controlled  through  careful  design.  A  larger  diameter 
fiber  of  given  numerical  aperture  resists  microbending  better  adding  support  to  the  argument  favoring  its  use.  Also,  to  keep 
microbending  induced  problems  to  a  minimum,  the  ratio  of  core  to  cladding  diameter  (the  aspect  ratio)  should  not  be  too  great  unless 
high  numerical  aperture  (NA)  fibers  are  used[15,16].  Other  factors  discourage  the  use  of  high  NA  fibers;  thus  an  aspect  ratio  of  0.7 
or  less  is  preferable.  This  limit  corresponds  to  100/140  or  200/280  core/clad  ratio  fibers.  Despite  this  rule  of  thumb,  there  are  higher 
aspect  ratio  fibers  being  used  with  success  on  aircraft  at  this  time. 

Externally  induced  loss  comes  from  the  effects  of  bends  put  into  the  cable  during  installation  (macrobends).  To  keep  this  to 
a  small  percentage  of  the  intrinsic  loss,  it  is  only  necessary  to  conduct  the  aircraft  cable  fabrication  and  installation  process  in  a 
manner  consistent  with  the  requirements  of  the  technology.  Minimum  bend  radii  are  dependent  on  the  jacketing  construction,  fiber 
diameter,  and  installation  handling  including  the  tensile  loading  involved  in  the  installation.  For  nearly  any  case,  minimum  values  are 
comparable  to  those  specified  for  conventional  wire  of  similar  cable  size,  typically  an  inch  or  so.  Another  souree  of  induced  loss  is 
the  effect  of  nuclear  radiation  products,  both  electromagnetic  and  ionizing.  For  avionics  applications,  both  pure  and  doped  silica  core 
fibers  have  demonstrated  their  ability  to  perform  in  the  transient  environment,  at  low  temperature,  and  at  the  short  wavelengths  which 
high  power  LEDs  produce.  Fibers  with  the  best  performance  in  this  environment  have  relatively  low  numerical  apertures  (0.2  to 
0.25).  Therefore,  if  nuclear  radiation  hardness  is  required,  a  fiber  must  be  chosen  which  is  compatible  with  the  other  effects 
discussed. 

The  optical  fiber  not  only  attenuates  the  signal  but  also  distorts  it.  Two  effects  contribute  to  pulse  distortion  in  multimode 
fibers:  modal  dispersion  and  the  material  component  of  chromatic  dispersion.  These  terms  do  not  directly  affect  the  static  loss  budget 
or  link  margin  but  have  a  dynamic  effect  when  the  receiver  performance  is  included.  Thus  il  is  necessary  to  carefully  consider  these 
factors  to  be  sure  the  fiber  which  is  selected  based  on  other  reasons  does  not  create  a  problem  for  the  system  when  it  is  all  put 
together.  Modal  dispersion  results  from  different  modes  (rays)  taking  different  paths  inside  the  fiber.  In  principle,  a  larger  diameter 
fiber  will  have  a  larger  modal  dispersion,  for  a  given  numerical  aperture,  because  optical  path  differences  are  greater.  This  can  be 
offset  with  lower  NAs  in  larger  fibers.  Also  step-  index  fiber  has  greater  modal  dispersion  than  graded-index  fiber.  At  850 
nanometers,  a  typical  value  for  100  meters  of  200  micrometer  core  semi-graded-index  fiber  is  2  nanoseconds,  flare  must  be  exercised 
in  interpreting  manufacturer's  "fiber  bandwidth”  specifications  since  die  actual  dispersion  which  results  is  sensitive  to  both  the  length 
(it  is  not  linear)  and  the  test  or  launch  conditions  for  the  fiber. 

Material  dispersion  results  because  different  wavelengths  (colors)  travel  through  the  fiber  at  different  speeds.  Thus  the 
broader  the  spectrum  of  an  optical  source,  the  greater  the  dispersion.  This  factor  also  decreases  with  increasing  wavelength  to  a  point. 
Since  850  nanometer  LED  sources,  with  spectral  widths  in  the  order  of  50  nanometers,  are  preferred  for  this  sytem  because  of  the 
large  available  transmitter  power,  the  material  dispersion  component  is  not  negligible.  At  this  wavelength,  a  typical  value  is  0. 1 
nanoseconds  per  nanometer  per  kilometer.  For  a  50  nanometer  spectral  width  and  100  metets  of  fiber,  the  material  dispersion  is  0.5 
nanosecond.  The  net  dispersion  is  the  root-sum-squared  value  of  the  two  components  or  2.06  nanoseconds.  Summing  this  in  a  like 
manner  with  the  transminer's  rise  and  fall  times  results  in  a  value  for  the  rise  and  fall  time  of  the  optical  pulse  incident  on  the  receiver's 
photodetector.  This  data  is  then  used  to  determine  the  receiver  bandwidth  required  to  insure  an  "eye”  opening  adquate  to  maintain  a 
specified  probability  of  detection  (bit  error  rate). 

For  aircraft  applications,  the  cost  of  200  micrometer  core  optical  fiber  should  not  be  significantly  greater,  if  at  all,  than  the 
smaller  100  micrometer  fiber  since  the  raw  material  cost  is  not  dominant,  and  the  process  for  manufacturing  larger  fiber  is  not  much 
different  With  both  sizes  of  jacketed  fiber  optic  cables  now  flying  on  commercial  and  miiitaiy  aircraft  in  different  parts  of  the  worid, 
there  should  be  little  reluctance  to  embrace  either  as  a  standard  With  the  advantage  the  larger  her  offers  in  terms  of  modal  volume 
and  coupled  power,  it  is  the  preferred  choice.  Typical  examples  of  fiber  optic  cable  losses  are  zero  decibels  for  transmitter-to-receiver 
path  lengths  near  zero  and  2  dB  for  the  longest  path  which  has  the  highest  intrinsic  and  macrobending  loss  and  a  1  dB  penalty  for 
radiation  induced  degradation.  These  are  reasonable  values  for  path  lengths  that  will  not  exceed  100  meters. 


9.  THE  ACCESS  COUPLER 

Fused  biconical-taper  star  couplers  with  up  to  100  inputs  and  outputs  were  being  fabricated!  17]  shortly  after  the 
announcement  of  the  concept  [13].  They  can  be  made  with  any  number  of  inputs  and  outputs,  but  standard  products  usually  have  a 
power-of-two  of  them  (2,4, 8,  16,  etc.)(18].  Larger  couplers  are  not  necessarily  more  difficult  to  make  than  small  ones;  they  just 
have  higher  splitting  loss  -  -  3  dB  mote  for  every  doubling  of  the  number  of  inputs/outputs.  The  larger  number  of  fibers  also  means 
more  connections  which  imacts  the  physical  requirements  for  housing  the  coupler.  Most  couplers  manufactured  to  date  are  made  with 
100  micrometer  core  fiber  or  smaller.  However,  couplers  with  200  micrometer  fiber  have  been  made  and  may  be  producible  with 
higher  yield.  The  larger  fiber  size  also  means  the  uniformity  of  output  power  will  be  better  and  the  overall  excess  loss  generally  will 
be  less  if  the  right  fiber  is  used 
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Recent  tests  of  commercial -grade  access  couplers  to  Class  3  avionics  equipment  environmental  exposures  have  been 
particularly  encouraging  (19].  The  tests  included  mechanical  shock,  vibration,  thermal  shock,  thermal  range,  humidity,  and  salt 
spray.  The  thermal  shock  test  ranged  from  -55°C  to  +125®C  The  coupling  factor,  backscatter,  excess  loss,  and  output  uniformity 
were  observed.  Despite  these  units  being  intended  for  commercial  applications,  several  passed  all  Class  3  tests  and  showed  little 
degradation  as  a  result  The  32  x  32  port  coupler  which  passed  also  had  the  best  performance  prior  to  testing.  Clearly,  these 
components  of  the  system  are  suitable  for  the  avionics  environment  and  can  be  militarized  without  extensive  investment.  The  best  32 
x  32  port  coupler  in  the  tests  had  a  mean  coupling  factor  of  16.7  dB,  just  1.7  dB  above  "ideal’'  (the  ideal  being  10  log  32  =  15  dB). 
Output  uniformity  (the  difference  in  dB  between  the  maximum  and  minimum  coupling  factors)  was  only  1.1  dB.  After  passing  all 
tests,  the  mean  coupling  factor  was  17.7  dB,  and  uniformity  1.6  dB. 

A  high  quality  64  port  coupler  fabricated  with  100  or  200  micrometer  core  fiber  will  have  superior  uniformity  figures  and  be 
less  likely  to  have  a  "hot"  fiber.  Poorly  fabricated  couplers  have  considerably  more  power  in  the  output  fiber,  corresponding  to  the 
input  being  driven  (the  hot  one),  than  in  the  other  output  fibers.  The  following  coupler  loss  values  are  representative.  The  ideal  loss 
is  1 0  log  64  ^  18  dB.  For  the  worst  case  coupler,  it  is  assumed  there  is  a"hotN  fiber  and  the  coupling  factor  or  loss  for  that  path  is  17 
dB.  Thus,  a  particular  transmitter  is  connected  to  one  receiver  by  a  path  that  has  only  17  dB  loss  through  the  coupler.  The 
port -to- port  uniformity,  excluding  the  hot  fiber,  is  2.5  dB  for  the  200  micrometer  fiber  coupler,  a  value  smaller  by  about  0.5  dB  from 
that  for  a  coupler  made  with  100  micrometer  core  fiber.  The  total  range  of  coupling  factors  or  loss  is  therefore  a  minimum  of  17  dB 
and  a  maximum  of  20.5dB  This  concludes  the  consideration  of  all  components  except  the  receiver.  Before  any  particular  receiver 
design  is  chosen,  however,  several  system  parameters  need  to  be  considered.  Numerical  values  for  them  are  derived  from  the 
foregoing  discussion. 


10.  THE  INTERTRANSMISSION  DYNAMIC  RANGE  AND  RECEIVER  OPERATING  RANGE 

Before  choosing  a  receiver,  it  is  necessary  to  understand  the  dynamic  environment  in  which  it  must  work.  Some  designs  are 
simply  not  suitable  to  data  buses,  and  others  are  questionable.  So,  as  many  variables  as  possible  must  be  understood  before 
committing  to  a  technical  approach. 

Without  introducing  any  new  numerical  quantities,  the  intertnmsmission  dynamic  range  (IDR),  and  required  receiver 
operating  range  (ROR)  can  be  determined.  This  bus  operates  by  consecutive  transmitters  sending  bursts  of  information  of  varying 
length.  A  minimum  length  of  time  between  consecutive  receptions  is  specified  to  insure  the  quality  of  the  transmissions.  Thus  any 
given  receiver  gets  these  receptions  via  different  paths  with  different  losses.  The  maximum  range  of  peak  optical  power  which  can 
occur  for  this  situation  in  a  particular  configuration  is  called  the  IDR.  In  addition,  if  a  single  receiver  design  is  to  be  used  at  all 
terminals  it  must  handle  an  even  greater  dynamic  range  to  accommodate  all  transmissions  (not  just  consecutive  ones)  over  all  operating 
conditions,  from  the  best  case  to  the  worst  case.  This  range  is  called  the  required  ROR.  The  two  quantities  will  now  be  derived  based 
on  the  data  previously  presented. 

The  IDR  is  the  difference  in  loss  for  the  paths  to  any  receiver  with  the  highest  and  lowest  losses.  To  find  the  numerical 
value  for  the  system  in  this  study,  it  is  only  necessary  to  add  up  the  differences  for  each  of  the  components  involved.  But  what 
components  are  involved?  Since  the  path  to  any  given  receiver  from  any  two  transmitters  is  the  same  from  the  output  of  the  access 
coupler  to  the  receiver,  the  components  in  this  path  do  not  contribute  to  a  difference  in  loss.  So  what  must  be  found  is  the  lowest  and 
highest  loss  paths  from  two  transmitters  to  and  including  the  access  coupler.  The  low  loss  path  in  this  design  example  includes  the 
highest  power  transmitter,  the  fewest  connectors  (three:  at  the  transmitter,  rack  and  coupler),  the  lowest  connector  losses,  essentially 
zero  fiber  length,  and  the  lowest  coupler  loss.  The  high  loss  path  has  the  lowest  power  transmitter,  tl  e  most  connectors  (four:  at  the 
transmitter,  rack,  one  bulkhead,  and  coupler),  the  highest  connector  losses,  the  maximum  fiber  length  (100  meters),  and  the  highest 
coupler  loss.  Table  2  lists  the  numerical  values  associated  with  each  path.  Note  that  there  are  no  absolute  power  levels  (dBm);  only 
differences  (dB)  are  needed  to  find  the  IDR.  A  6  dB  difference  in  LED  power  was  previously  computed  for  the  worst  case 
(temperature  compensation  is  assumed).  For  the  connectors  other  than  at  the  coupler,  a  2.5  dB  difference  is  assigned,  and  at  the 
coupler's  input  connector  1.5  dB.  The  fiber  loss  ranges  from  zero  to  2  dB,  and  the  access  coupler  loss  varies  from  17  to  20.5  dB. 
The  use  of  200  micrometer  core  fiber  is  assumed  in  this  example.  The  result  is  a  15.5  dB  IDR. 

Table  2.  Calculating  the  Intertransmission  Dynamic  Range  (IDR). 


Loss  Contrtoution 
(dB) 

Best 

Worst  J 

Transmitter 

0 

Connectors 

2 

6 

Fiber 

0 

2 

Access  Coupler 

17 

20.5 

TOTAL 

19 

34.5 

Difference  (IDR) 

15.5 
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The  required  receiver  operating  range  is  calculated  in  a  similar  manner,  but  now  the  lowest  and  highest  loss  paths  from  the 
access  coupler  outputs  to  receivers  must  be  included.  By  adding  the  value  of  the  Jowesr  .transmitter  power  to  the  worst  case  path  loss, 
the  minimum  power  incident  on  the  receiver  is  known.  Any  link  margin  added  to  that  specifies  the  sensitivity  required  for  a  single 
receiver  design  to  support  the  entire  data  bus.  The  development  of  these  quantities  is  illustrated  in  Figure  11.  From  Table  1,  a  6  dB 
range  of  temperature  compensated  transmitter  peak  powers  from  +  2  dBm  to  -4  dBm  may  be  found.  The  range  of  losses  for  the 
connectors  other  than  those  at  the  access  coupler  is  1  dB  to  6dB.  Note  that  there  may  be  no  talkhead  connectors  in  a  given  path;  thus 
the  loss  for  them  is  zero  decibels.  The  coupler's  two  connectors  range  from  3  dB  to  6  dB.  Together,  all  connectors  are  allowed  a  loss 
range  from  4  dB  to  12  dB.  The  fiber  best  case  loss  is  zero  dB  for  a  short  path;  the  worst  is  2  dB  for  a  100  meter  path  with  a 
permanent  lots  contribution  of  1  dB  due  to  radiation  effects.  The  access  coupler  loss  is  the  same  here  as  above:  17  dB  to  20.5  dB. 
The  results  are  summarized  in  Table  3.  The  receiver  will  have  to  have  a  sensitivity  equal  to  or  greater  than  the  worst  case  value.  Its 
operating  range  is  19.5  dB  and  extends  from  -38.5  dBm  to  -19  dBm.  With  this  information,  the  process  of  matching  the  interconnect 
system  to  a  receiver  can  begin. 


> 
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Figure  1 1  Development  of  the  Power  Budget  and  Matching  it  to  the  Optical  Receiver. 


11.  THE  HSDB  RECEIVER  CHOICES 

The  results  so  far  indicate  that  a  high  sensitivity,  wide  dynamic  range  receiver  will  be  required  to  support  this  system.  As 
little  as  -38.5  dBm  peak  may  be  incident,  and  in  the  worst  case  the  input  could  range  over  19.5  dB.  So  what  kind  of  receiver  will 
fulfill  the  requirement? 

Fiber  optic  receivers  for  the  HSDB  can  be  classified  as  ac-coupled,  edge-coupled,  or  dc -coupled.  Refer  to  Figure  12.  All  3 
typically  incorporate  a  photodetector  and  band-limited  transimpedanre  preamplifier  in  the  "front-end.”  The  distinction  between  types 
begins  at  this  point.  The  first  two  designs  use  ac-coupling  prior  to  data  detection.  The  first  is  generally  referred  to  as  an  ac-coupled 
receiver.  The  front  end  is  followed  by  additional  gain  stages  as  required.  The  output  is  capacitively  coupled  to  a  zero-reference 
comparator  or  hard  limiter  for  waveshaping  and  amplitude  matching  to  a  standard  digital  interface  such  as  emitter-coupled  logic 
(ECL).  A  long  time  conr.u  f  is  used  in  the  capacitive  coupling  to  preserve  the  optical  waveform  to  some  defined  extent.  The  dc  offset 
buildup  in  the  gain  stages  r  .einoved  in  the  ac-coupling. 

Table  S.  Calculating  the  Required  Receiver  Operating  Range  (ROR)  and  Minimum  Input  Power 


Best 

Worn 

Transmitter  Output  (dBm) 

-4 

Connector  Lom  (dB) 

1  | 

12 

Fiber  Lom  (dB) 

XX 

2 

Access  Coupler  Loss  (dB) 

17 

20.5 

Receiver  Input  (dBm) 

19 

38  5 

Receiver  Operating  Range 

19.5  dB 

The  second  ac-coupled  type  is  called  an  edge-coupled  or  differentiating  receiver.  The  front  end  output  is  ac-coupled  with  a 
short  time  constant  to  a  post  amplifier  and  Schmitt  trigger  with  hysteresis.  The  output  is  buffered  as  required  to  provide  a  standard 
digital  logic  interface  such  as  ECL.  The  preamplifier's  dc  offset  is  removed  by  the  differentiating  capacitors.  The  post  amplifier's  dc 
offset  is  removed  by  the  hysteresis  in  the  data  threshold  detector  (the  Schmitt  trigger).  Hysteresis  is  required  to  prevent  false 
triggering  on  noise. 

A  fully  dc-coupled  receiver  has  no  capacitive  coupling  between  the  optical  input  and  data  detector.  Since  there  is  a  large 
amount  of  dc  offset  at  the  input  to  the  data  detector,  some  form  of  edge-detecting  process  is  required.  A  threshold  must  be  established 
based  on  the  average  value  of  the  input  waveform  in  order  to  make  bit  decisions.  Usually,  several  delay  lines,  gain  stages,  logic 
elements,  and  comparators  are  necessary  to  implement  this  circuit  It  is  often  called  an  edge-detecting  receiver  (not  to  be  confused 
with  edge-coupled  receiver). 

A  few  general  comments  on  the  receivers  follow.  For  optimum  performance,  the  frequency  response  of  the  preamplifier 
must  be  matched  to  the  rest  of  the  network.  Specifically,  since  the  transmitter  output  is  band-limited,  the  receiver  must  be 
compensated  correctly.  Thus  the  transmitter  and  receiver  designs  must  be  considered  together.  Also,  the  frequency  response  of  the 
preamplifier  may  affect  the  overall  receiver  performance  depending  on  the  ciruciL-  which  follow  the  low-pass  filter.  Thus  the  same 
transimpedance  preamplifier  may  not  be  the  best  choice  for  all  three  receiver  types.  In  general,  a  specific  receiver  design  is  driven 
primarily  by  the  requirement  for  a  quantitative  measure  of  performance  given  by  the  probability  of  error  (bit  error  rate).  That  in  turn  is 
qualitatively  indicated  by  the  "eye"  pattern  the  receiver  output  produces.  The  "openness"  of  die  eye  is  determined  by  numerous  factors 
only  a  few  of  which  have  been  indicated  here. 

The  choice  of  receiver  type  is  driven  by  several  factors  including  certain  properties  of  the  protocol  discussed  in  Section  3. 
To  achieve  the  high  sensitivity  and  wide  dynamic  range  operation  for  the  passive  star-coupled  data  bus,  the  ac-coupled  receiver  is  the 
most  arttractive.  It  has  limitations,  but  they  are  not  in  sensitivity  and  dynamic  range.  This  type  only  works  well  with  signals  obeying 
constrained  run-length  (CRL)  codes  and  optimum  performance  is  obtained  when  the  duty  cycle  is  exactly  50%.  A  sensitivity  penalty 
is  paid  if  the  steady-state  duty  cycle  is  different  However,  CRL  codes  such  as  the  4B5B  +  NRZI  or  8B10B+  NRZI  block  codes, 
which  have  short  term  duty  cycle  variations  from  40  to  60%,  have  a  long  term  duty  cycle  which  approaches  50%  as  the  message 


► 


7-11 


length  increases.  The  ac -coupled  receiver  has  link  difficulty  with  these  data  codes  and  the  sensitivity  penalty  resulting  from  the  slight 
amount  of  "baseline  wander"  which  results  is  small,  less  than  1  dB,  typically. 
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Figure  12.  The  HSDB  Receiver  Choices. 


Since  the  receiver  must  work  in  a  burst  mode  environment  over  a  potentially  large  (15.5  dB)  intertransmission  dynamic 
range,  it  must  be  given  sufficient  time  to  adapt  to  each  new  signal  level.  The  receiver  thus  has  an  acquisition  time  associated  with  it 
after  which  it  responds  properly  to  the  CRL  code  for  which  it  was  designed  The  acquisition  time  is  a  function  of  the  time  constant  of 
the  high-pass  filter  and  is  accommodated  by  the  combined  intertransmission  gap  time  and  preamble  length  (in  time) [20).  The  purpose 
of  the  preamble  is  to  get  the  receivers  operating  levels  established  and  the  clock  recovery  circuitry  running  in  phase  with  the  data;  so  it 
is  a  contributor  in  the  acquisition  process.  Thus  an  ac-coupled  receiver  best  serves  the  need  of  this  data  bus  as  Jong  as  sufficient 
acquisition  time  is  provided  and  an  appropriate  CRL  data  code  is  used 

Few  maximum  sensitivity,  the  receiver  bandwidth  must  be  minimized.  The  bandwidth  required  to  achieve  a  given  level  of 
performance  (bit  error  i ate)  is  determined  by  the  quality  of  the  optical  signal  incident  on  the  receiver  as  measured  by  its  rise  and  fall 
time  and  pulse  width  distortion.  The  higher  the  quality  of  the  input,  the  lower  the  bandwidth  needed  to  produce  a  given  BER.  The 
data  code  used  directly  drives  the  bandwidth  needed  for  the  entire  data  channel  including  that  of  the  receiver.  For  example,  the  block 
codes  mentioned  above  impose  a  25%  penalty  on  required  signaling  rate  over  the  NRZ  data  rate  whereas  a  code  such  as  Manchester, 
usually  used  for  low  data  rate  systems,  imposes  a  100%  penalty  (i.e.,  the  signaling  (baud)  rate  is  twice  the  NRZ  data  rate).  At  the 
data  rates  involved  in  this  system  (50  Mbps)  this  translates  into  a  3  dB  sensitivity  penalty  for  Manchester  compared  to  8B 10B  + 
NRZ1.  Nevertheless,  a  requirement  in  the  Pave  Pillar  HSDB  and  related  buses  is  the  use  of  Manchester  encoding,  and  a  receiver  with 
bandwidth  sufficient  to  support  a  100  Mbaud  signaling  rate  is  necessary. 

12.  THE  RECEIVER  DESIGN 

The  system  measure  of  performance,  the  bit  error  rate,  is  a  function  of  the  signal- to-noise  ratio  (SNR)  at  the  receiver  input 
and  the  offset  and  hysteresis  performance  of  the  data  detector.  The  principal  noise  sources  are  diode  shot  noise,  the  preamplifier 
input  transistor  thermal  and  shot  noise,  and  the  feedback  resistor  thermal  noise.  The  diode  contributes  the  least  to  the  total  since  its 
noise  current  is  proportional  to  the  square  root  of  the  dark  current  in  a  pin  photodiode,  and  to  a  portion  of  the  dark  current  multiplied 
by  a  gain  factor  for  an  avalanche  photodiode  (APD).  The  preamplifier's  noise,  being  directly  related  to  bandwidth,  is  minimized  by 
keeping  the  bandwidth  as  small  as  possible.  The  amount  of  signal  necessary  to  achieve  the  SNR  corresponding  to  the  desired  BER  is 
the  preamplifier’s  sensitivity. 

A  detailed  receiver  design  analysis  is  not  within  the  scope  of  this  paper.  The  reader  is  referred  to  any  of  a  large  number  of 
articles  (such  as  [21])  which  allow  a  designer  to  quantify  the  receiver  performance.  The  results  of  a  HSDB  receiver  design  at  the 
Harris  Corporation  which  was  then  followed  by  fabrication  and  a  performance  evaluation  is  presented  here  and  used  to  complete  the 
receiver  matching  process.  An  ac-coupled  receiver  with  pin  photodiode,  optimized  for  operation  at  100  Mbaud  with 
Manchester-encoded  data,  designed  to  operate  ud  to  105°C  junction  temperature,  and  packaged  to  achieve  the  lowest  noise  figure, 
can  achieve  a  -34  dBm  (peak)  sensitivity  at  10" 10  BER  and  24  dB  dynamic  range  for  50%  duty  cycle  signals.  Unfortunately  it  does 
not  have  enough  sensitivity  to  meet  the  system  requirement  of  -38.5  dBm.  Refer  to  Figure  1 1. 

To  make  this  network  work  with  a  pin  photodiode  receiver,  it  is  necessary  to  reduce  link  losses  or  increase  transmit  power 
'  y  4.5  dB.  Lower  link  loss  is  best  achieved  by  reducing  the  number  of  connectors  in  the  system.  Designing  the  platform  with  fiber 
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optic  technology  in  mind  may  lsuke  this  possible.  For  example,  the  use  of  permanent  cabling  splices  where  an  airframe  is  permanently 
spliced  would  help.  Increased  transminer  power  is  also  a  possibility  in  the  forseeable  future.  However,  yet  another  alternative  exists: 
use  an  avala^iohe  photodiode  receiver.  Although  an  APD  requires  a  low  current,  high  voltage  bias  supply,  the  device  reliabilty  is  no 
longer  questioned.  It  is  important,  however,  that  the  APD  not  be  biased  for  too  much  avalanche  gain.  Otherwise  its  thermal 
properties  will  cause  the  gain  to  decrease  at  high  input  power  levels  (which  is  not  necessarily  bed),  but  if  followed  by  a  low  input 
power  signal,  the  gain  will  not  be  sufficient  for  normal  receiver  operation.  This  thermal  effect  is  minimized  by  biasing  the  diode  for  a 
low  gain  (about  10).  If  too  low  a  bias  voltage  is  used,  the  diode’s  bandwidth  decreases  drastically  which  is  not  acceptable  either. 
Thus  the  APD  works  best  in  this  application  when  optimally  biased.  Replacing  the  pin  diode  with  an  APD  yields  -42.5  dBm 
sensitivity  for  10"  BER  and  23  dB  dynamic  range.  This  is  more  sensitivity  than  required,  but,  as  was  pointed  out,  if  it  is  reduced 
by  reducing  APD  gain,  bandwidth  will  be  sacrificed.  The  best  engineering  solution  to  the  range  offset  is  to  compensate  the  link  power 
budget  and  match  it  to  the  best  available  receiver. 

The  match  can  be  achieved  in  several  ways.  One  is  to  reduce  transminer  power  across  the  board.  As  Figure  1 1  shows,  a 
link  budget  downward  compensation  of  2.25  dB  centers  the  required  19.5  dB  receiver  operating  range  in  its  23  dB  dynamic  range  and 
leaves  a  1 .7  dB  headroom  and  link  margin.  So  the  LEDs  can  be  further  derated  by  2.25  dB.  Another  option  is  to  use  100 
micrometer  core  optical  fiber  and  increase  the  expected  connector  loss  by  several  decibels.  Optical  attenuators  could  also  be  added, 
but  that  is  not  a  recommended  approach  .The  link  margin  which  was  derived  for  this  system  was  1 .75  dB  minimum.  That  means  that 
in  the  worst  case  with  lowest  transmitter  power,  and  highest  connector,  cable,  and  coupler  losses,  there  will  still  be  1.75  dB  more 
power  incident  on  the  receiver  than  is  required  for  a  specified  BER,  10'^  here.  Noting  that  the  slope  of  the  BER  versus 
signal-to-noise  ratio  curve  is  approximately  4  orders  or  magnitude  per  dB  at  10"^  BER,  this  system,  with  only  -40.75  dBm  incident, 
will  have  a  BER  of  about  10*  Under  more  typical  operating  conditions,  one  might  expect  intertransmission  dynamic  ranges  of  7  to 
10  dB,  and  a  nominal  receiver  input  power  of  -26  dBm  peak.  In  this  case  the  link  margin  is  42.5  -  26  =  16.5  dB. 

We  have  shown,  based  on  measured  component  performance  data,  that  a  passive  star-coupled  serial  high  speed  data  bus 
physical  layer  suitable  for  use  on  future  military  airborne  platforms,  and  meeting  the  requirements  set  forth  by  the  Pave  Pillar 
requirements  can  be  built  Next  we  wish  to  show  still  another  implementation  of  the  physical  layer  hardware,  one  based  on  the  use 
of  a  repeater  or  regenerator  (an  "active”  star)  instead  of  a  passive  access  coupler. 


13.  THE  ACTIVE  STAR-COUPLED  NETWORK 

In  the  most  elementary  active  star-coupled  network,  the  passive  access  coupler  shown  in  Figure  9  is  replaced  by  a  repeater  or 
regenerator  station.  It  has  the  same  number  of  optical  inputs  and  outputs  and  also  needs  power  to  operate. 

Before  we  consider  the  contents  of  the  active  star,  let  us  examine  why  we  would  use  it.  We  already  showed  how  a  passiv  * 
implementation  of  the  HSDB  can  be  built  with  a  nominal  16.5  dB  link  margin,  that  is  up  to  16.5  dB  of  loss  can  be  added  to  a  normal 
operating  path  and  the  network  will  still  operate  as  designed,  that  is  it  will  meet  the  required  bit  error  rate  performance.  Possible 
reasons  for  using  it  include,  the  APD  photodetector  cannot  be  used  because  of  the  size,  weight,  and  power  penalties  of  its  power 
supply  (10  dB  penalty,  6.5  dB  net  link  margin);  plus  the  need  for  large  numbers  of  connectors  (4  more  at  2  dB  loss  each,  - 1.5  dB  net 
link  margin);  or  the  use  of  high  loss,  non-state  of  the  an  connectors  (add  8  dB  loss  to  the  baseline,  - 1 .5  dB  net  link  margin),  or  the 
requirement  to  operate  at  a  different  wavelength  (such  as  1 300  nm)  where  the  increase  in  receiver  sensitivity  due  to  higher  responsivitv 
pin  photodiodes  cannot  offset  the  considerably  lower  coupled  optical  power  available  from  LEDs  (10  dB  net  penalty  with  n 
temperature  compensated  transmitter,  -3.5  dB  net  link  margin);  and  so  on.  Whatever  the  reason  or  reasons  may  be,  it  is  possible  to 
recover  lost  link  margins  by  the  use  of  a  repeater  or  regenerator  in  place  of  the  passive  star  coupler. 

When  this  is  done,  note  the  following  properties  of  the  fiber  optic  network.  The  ABI  receivers  are  effectively  moved  into  the 
active  star  so  there  will  be  more  incident  power  on  the  detector.  The  receiver  operating  range  will  be  reduced  since  there  are  fewer  path 
options,  but  the  intertransmission  dynamic  range  is  essentially  unchanged.  Actually,  the  ROR  and  IDR  are  equal  if  the  active  star  can 
be  built  with  one  receiver.  The  ABI  transmitters  are  effectively  moved  to  the  output  of  the  active  star  so  all  connections  from  the  active 
star  to  all  ABI  receivers  are  point-to-point  links.  This  means  there  is  no  IDR  requirement  for  the  ABI  receivers  any  longer.  All 
transmissions  to  any  QU£  receiver  will  have  the  same  short  term  peak  power  level.  However,  since  the  paths  to  all  receivers  may  have 
different  losses,  the  ABI  receivers  must  have  a  non-zero  operating  range  if  one  type  is  to  be  used  at  all  terminals.  Thus  there  is  some 
relaxation  of  performance  requirements  for  the  receivers  that  suggests  a  reconsideration  of  the  type  for  an  active  network 
implementation. 


14.  THE  ACTIVE  STAR  TECHNICAL  ISSUES 

When  designing  an  active  star,  the  overall  goal  is  to  insure  that  the  performance  degradation  of  the  HSDB  is  minimized. 
This  means  the  net  data  throughput  rate  must  not  be  reduced  significantly.  This  could  occur  if  the  propagation  delay  through  the  active 
star,  which  is  affected  by  receiver  acquisition  time,  is  large;  if  there  is  significant  pulse  width  distortion  and  jitter  forcing  the  active  star 
to  employ  clock  recovery  techniques  to  retime  the  transmitted  signal;  or  if  undesirable  changes  to  the  protocol  are  necessary  to 
implement  the  active  star.  The  active  star  must  also  have  adequate  optical  signal  gain  to  provide  a  network  link  margin  meeting  the 
system  needs.  This  is  met  by  a  careful  balance  of  other  link  budget  parameters,  especially  transmitter  power  levels  and  receiver 
sensitivities  at  all  locations  (ABIs  and  active  star).  Most  of  the  factors  mentioned  interact  in  some  way,  so  it  is  not  possible  to  create 
an  optimum  active  star  design  without  going  through  an  iterative  process 

Propagation  delay  through  the  active  star  is  minimized  by  making  the  receiver  acquisition  time  small.  From  Figure  12,  the 
clear  choice  here  is  the  edge -coupled  receiver  which  offers  a  good  compromise  between  sensitivity  and  acquisition  time  performance. 
However,  the  8  dB  or  more  penalty  in  sensitivity  over  the  ac-coupled  receiver  can  erase  any  benefit  the  active  s*ar  offers  in  optical 
signal  gain  unless  an  efficient  method  of  active  stv  receiver  utilization  is  employed.  Most  clock  recovery  circuits  also  have  an 
associated  acquisition  tune  and  will  contribute  to  the  propagation  delay.  The  best  case  is  not  needing  a  clock  recovery  circuit  for 
retiming,  but  that  will  be  driven  by  the  pulse  width  distortion  and  jitter  performance  of  the  two  concatenated  data  limits  (ABI  TX  to 
active  star  RX,  and  active  star  TX  to  ABI  RX).  Any  logic  required  between  die  active  star  receivers  and  transmitters  will  add  delay. 
The  transmitters  themselves  only  add  a  few  bit  times. 

Should  either  an  ac-coupled  receiver  be  used,  or  a  clock  recovery  unit  be  needed,  the  non- zero  acquisition  time  may  require 
that  either  the  active  star  reconstruct  the  message,  or  the  ABTs  transmitted  preamble  be  lengthened.  After  the  active  star’s  receiver 
acquires  the  optical  signal,  the  ABI  receiver  must  acquire  the  active  star’s  output  But  the  active  star  receiver  ’’absorbed’’  a  piece  of  the 
preamble  and  the  ABI  receiver  must  acquire  with  a  shortened  preamble.  If  reclocking  is  also  required  in  the  repeater,  addtional 
preamble  will  be  lost  during  the  clock  recovery  unit  acquisition  time.  For  the  single  active  star  configuration  shown  in  Figure  9,  two 
solutions  exist.  Change  the  protocol  by  increasing  the  preamble  length  (from  16  to  32  bits,  for  example)  to  satisfy  the  worst  case. 
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This  approach  results  in  the  smallest  hardware  impact  but  does  require  a  minor  protocol  change  which  may  be  unacceptable.  The 
alternative  is  to  decode  the  incoming  message  and  append  a  new  preamble  and  start  delimiter  to  it.  This  method  requires  more 
hardware  including  a  20  bit/40  baud  storage  register.  Message  reconstruction  eliminates  distortion  problems,  however,  and  since  the 
hardware  penalty  will  Ik  small  if  the  logic  is  implemented  in  a  gate  array,  this  approach  is  reasonable.  The  major  difficulty  with  it  is 
the  demand  placed  on  the  clock  recovery  unit  that  is  needed.  The  clock  signal,  derived  from  incoming  data,  must  now  be  used  to 
clock  data  through  all  the  logic  hardware  to  the  active  star’s  transmitter.  Included  in  this  hardware  is  a  400  ns  long  storage  register 
which  contains  the  last  40  betid  of  the  message.  Thus,  at  least  40  clock  cycles  are  required  after  the  end  of  incoming  data.  This  is  a 
difficult,  if  not  impossible,  task  for  a  fast-acquisition  clock  recovery  unit.  Alternatively,  the  storage  register  could  be  implemented  as 
a  FIFO  (First-In,  First-Out)  memory  and  a  continuous  clock  (crystal  oscillator)  could  be  used  on  the  transmit  side.  However,  a  high 
speed  FIFO  memory  will  require  more  space  and  additional  power  which  may  make  this  approach  even  less  attractive. 

On  the  subject  of  pulse  width  distortion,  presently  available  high-radiance  LEDs,  with  3-5  ns  rise  and  fall  times  operated  at 
10  ns  baud  times,  even  with  compensation,  will  have  some  pulse  width  distortion  of  the  transmitted  waveform.  The  optical  receiver 
may  also  add  to  the  overall  distortion  and  jitter.  Therefore,  the  non-ideal  output  from  a  transmitting  AEI  may  be  further  degraded  in 
an  active  star  and  be  difficult  to  decode  by  the  AB1  receiver.  A  wide  bandwidth  receiver  and  high  speed  LED  transmitter  in  the  active 
star  will  minimize  the  problem,  but  wide  bandwidth  limita  receiver  sensidvity,  and  available  high-speed  LEDs  have  limited  output 
power.  If  a  message  is  digitally  reconstructed  and  retimed  in  the  active  star,  the  resulting  output  is,  obviously,  as  good  as  that  from 
the  ABI  transmitter.  The  need  for  retiming  must  be  determined. 


Active  star  optical  signal  gain  is  determined  by  (1 )  optical  combining  techniques  prior  to  the  receiver  input,  (2)  receiver 
sensitivity,  (3)  transmitter  output  power,  and  (4)  transmission  splitting  loss.  Refer  to  Figure  13,  The  64  input  fibers  must  be 
combined  into  one  optical  receiver  input  for  maximum  optical  gain.  An  "off  the  shelf  approach  is  to  use  one  output  of  a  64  x  64 
passive  star  coupler.  Here,  most  of  the  optical  power  is  lost  in  the  63  unused  fiber  outputs.  One  way  to  increase  gain  is  to  use 
multiple  receivers  precceded  by  smaller  passive  stars.  The  receiver  outputs  are  logically  ORed  into  a  single  electrical  output.  Other 
approaches  include  cutting  the  64  x  64  passive  star  coupler  in  half  and  coupling  the  truncated  taper  region  output  directly  to  a 
photodiode,  or  coupling  a  close-packed  array  of  64  fibers  directly  to  a  large  area  photodiode.  If  either  of  these  schemes  work,  the 
active  star  will  require  only  one  receiver.  Note  that  here  the  splitting  loss  of  a  64  x  64  passive  star  coupler  will  be  largely  avoided 
thereby  greatly  reducing  the  losses  between  an  ABI  transmitter  output  and  the  active  star  receiver. 
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Figure  13.  The  Active  Star  Components  Which  Determine  Optical  Signal  Gain. 

On  the  output  side  of  the  active  star,  the  situation  is  similar.  In  the  simplest  scheme,  the  power  output  of  one  transmitter  is 
divided  by  64,  but  the  losses  are  unacceptably  high.  There  are  two  ways  this  loss  can  be  reduced:  (1)  use  multiple  transmitters  with 
smaller  optical  splitters,  and/or  (2)  combine  the  splitter  and  LED  for  more  efficient  optical  coupling.  The  first  approach  is  "off  the 
shelf'  but  not  viable.  The  second  approach  requires  further  development,  hut  significant  improvement  in  efficiency  would  be 
achieved.  Here,  the  idea  is  to  exploit  the  fact  that  much  of  (he  energy  from  high  radiance  surface-emitting  LEDs  is  wasted.  Ball 
lenses  help  to  minimize  loss  but  cannot  focus  all  the  light  into  moderate  sized  optical  fiber  oores.  A  larger  core  fiber  or  close-packed 
fiber  array  will  clearly  capture  more  of  the  LED  output.  The  issue  of  uniformity  among  output  channels  must  be  considered, 
obviously 

Recall  that  there  was  no  intertransmission  dynamic  range  requirement  for  the  ABI  receivers  in  an  active  star  configuration 
because  all  connections  between  the  active  star  transminers  and  ABI  receivers  are  point-to-point.  Thai  suggests  the  possibility  of 
using  injection  laser  diodes  (tt-Ds)  in  the  active  star.  They  would  have  to  transmit  an  idle  pattern  during  the  normally  "dead"  time  on 
the  bus.  Modifications  to  the  protocol  machine  in  the  ABI  would  thus  be  necessary,  but  a  considerable  increase  in  coupled  output 
power  from  each  transmitter  results.  Fewer  transmitters  are  thus  needed  and  savings  on  size,  weight,  and  power  are  possible. 

15.  THE  ACTIVE  STAR  DISCUSSION 

Based  on  experience  gained  designing  and  building  fiber  optic  active  slirs(22J,  a  highly-efficiem  optical  combiner  (refer  to 
Figure  13)  in  conjunction  with  a  large  area  photodetector  is  practical.  An  edge-coupled  (differentiating)  receiver  (refer  to  Figure  12) 
provides  sufficient  sensitivity  for  a  large  link  margin  on  the  "left"  side  of  the  network  (refer  to  Figure  9  or  13).  Using  the  data  in 
Figure  11,  the  ABI  transmitter  delivers  +1  dBm  typical  into  a  200  micrometer  core-size  fiber.  With  half  the  connector  and  fiber  loss 
(for  the  "left"  side  only),  are)  no  coupler  loss  with  a  high -efficiency  optical  combiner,  there  is  -3dBm  typical  incident  on  the  detector. 
Using  an  edge-coupled  receiver  with  -26dBm  (peak)  sensitivity  provides  an  "artificial"  link  margin  of  23dB.  This  is  not  practical 
because  die  incident  power  level  is  already  at  the  top  of  the  receiver's  operating  range  for  typical  conditions.  Transmitter  power  must 
be  reduced  and  higher  interconnect  losses  must  be  assreed.  The  typical  incident  power  should  be  near  -10  to  -15  dBm  which  provides 
an  11  to  16  dB  link  margin  (the  same  as  the  passive  star  coupled  bus  with  A  PD)! 

Since  the  available  power  from  LEDs  for  the  active  star  transmitten  is  limited,  it  is  logical  to  use  high  sensitivity  ac-coupled 
receives  with  pin  photodiodes  in  the  ABIs.  This  means  acquisition  time  is  important  and  a  fuO  16  bit  preamble  must  be  delivered  to 
the  ABI  receiver.  If  a  nominal  16  dB  link  margin  is  desired  on  the  "right"  aide  of  the  network,  the  incident  power  on  the  detector 
ought  to  be  no  gBUBLthan  -18  dBm.  This  still  provides  a  5  -  8  dB  margin  on  die  high  power  side  of  the  receiver  operating  range. 
(This  assumes  a  21-24  dB  total  ROR.)  If  link  losses  are  the  same  on  both  "sides"  of  the  network  (4  dB  nominal),  then  the  active  star 
must  couple  -14  dBm  into  each  of  the  64  output  ports.  With  a  carefully  designed  optical  splitter  (are  Figure  13),  it  is  possible  to  use 
is  few  as  4  transmitters  with  the  LED  type  used  in  the  ABIs.  If  no  clock  recovery  circuitry  is  needed,  the  active  star  internal 
components  will  be  so  small  that  the  fiber  optic  connecton  totally  deminate  the  size  of  the  overall  active  star  package.  Propagation 
delay  is  minimal  and  no  modification  to  the  protocol  should  oe  necessary. 
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16.  FINAL  COMMENTS 

The  avionics  bus  interface  module  provides  the  gateway  between  a  parallel  internal  (PI)  bus  for  a  "rack"  of  processors, 
conveners,  etc.,  and  the  multiplex  high-speed  fiber  optic  data  bus  which  ties  together  all  the  "racks."  The  fiber  optic  bus  is  thus  the 
backbone  for  the  command  and  control  of  the  avionics  subsystem  of  an  aircraft.  An  overview  of  the  gateway  function  has  been 
presented  with  some  detail  regarding  the  origin  and  nature  of  the  different  protocols  used  for  the  Pi-bus  and  high  speed  data  bus. 
Emphasis  has  been  placed  on  the  design  process  used  to  implement  the  fiber  optic  network.  Numerous  options  are  available  each 
chosen  based  on  specific  application  requirements.  Both  passive  and  active  star-coupled  implementations  have  been  considered  in 
great  detail.  A  modestly-sued  subsystem  can  be  implemented  with  very  low  risk  (adequate  link  margin,  high  reliability)  using  pin 
photodiode-based  ac-coupled  receivers.  Full-sued  networks  (64  ABIs)  with  numerous  connectors  can  still  be  implemented  passively 
using  properly  biased  avalanche  photodiodes  in  conjunction  with  ac-coupled  receivers.  The  increase  in  risk  is  small  being  driven 
exclusively  by  the  reliability  associated  with  the  low-current,  low-power  bias  supply  for  the  APD. 

The  passive  versus  active  star-coupled  network  trade-off  has  a  particularly  interesting  result  When  the  impact  of  an  active 
star  on  network  data  throughput  is  used  as  the  most  important  factor  -  the  one  which  must  not  be  compromised  -  it  is  difficult  to 
show  a  significant  advantage  for  an  active  implementation  over  a  passive  one.  A  detailed  reliability  study  is  likely  to  show  a 
preference  for  a  passive  star-coupled  network  This  conclusion  may  not  be  valid,  of  course,  for  an  architecture,  data  bus  protocol, 
network  configuration,  or  measure  of  performance  other  than  the  one  selected  for  this  discussion.  It  appears  to  be  valid  for  the  Pave 
Pillar  HSDB  and  for  its  most  practical  configuration,  a  single  star-coupled  network. 

Although  packaging  of  the  ABI  has  not  been  discussed,  except  that  it  is  one  of  many  modules  in  a  rack,  this  is  a  most 
important  aspect  of  the  Pave  Pillar  architecture.  The  Standard  Electronics  Module  -  format  E  (SEM-E),  in  varying  widths,  has  been 
selected  to  house  most  avionics  functions  in  the  future.  A  photograph  of  such  a  module  is  shown  in  Figure  14.  Note  that  all 
connections  pass  through  a  single  backplane  connector,  including  power  and  ground,  discretes,  and  the  fiber  optic  connections  to  the 
HSDB.  There  are  now  several  suppliers  developing  connectors  for  this  function,  but  their  designs  are  currently  not  interchangeable 
or  lntcmut  [cable. 


Figure  14.  An  Avionics  Bus  Interface  Module. 


Several  manufacturers  are  currently  building  ABI  and  other  modules  for  demonstration  and  validation  of  the  Pave  Pillar 
avionics  architecture.  This  is  the  next  logical  step  toward  its  acceptance  and  use  in  the  next  generation  avionics  suite.  It  is  our  hope 
that  tins  paper  will  stimulate  additional  draught  on  the  subjects  presented  which  in  turn  leads  to  an  acceptable  implementation  standard 
for  all. 

17.  REFERENCES 

1 .  United  States  Air  Force,  Air  Force  Systems  Command,  "Architecture  Specification  for  the  Pave  Pillar  Avionics,”  AFWAL- 
TR-87-114, 1  May  1986. 

2.  International  Organization  for  Standardization  (ISO),  "Basic  Reference  Model  for  Open  Systems  Interconnection  (OSD.” 
IS 07498,  Geneva,  Switzerland,  1983,  (available  through  ISO  and  ANSI  New  York);  Zimmermann,  H.  "OSI  Reference  Model  - 
The  ISO  Model  of  Architecture  for  Open  Systems  Interconnection,’  IEEE  Transactions  on  Communications,  Vo)  COM-28,  No. 
4,  April  1980,  pp  423-432. 

3.  ANSI/IEEE,  -Logical  Link  Control,"  ANSI/IEEE  Standard  802.2  -  1983,  ISO/DIS  8802/2,  Token-Passing  Bus  Access  Method 
and  Physical  Layer  Specifications,"  ANSI/IEEE  Standard  802.4-1983, 1SCVDIS  8802/4,  Approved  17  December  1984. 

4.  Society  of  Automotive  Engineers  (SAE),  Aerospace  Systems  Division,  Corraninee  AS-2,  linear  Token-Passing  Multiplex  Data 
Bus,”  Draft  Standard  AS4074.1,  Version  4.0,  23  January  1988.  (Task  group  member  working  copy;  Current  configuration 
available  from  SAE,  Warrendale,  PA.,  U.S.A.). 


7-15 


5.  United  States  Air  Force,  Air  Force  Systems  Command,  "Architecture  Specification  for  the  Pave  Pillar  Avionics,"  AFWAL- 
TR-87-114, 1  May  1986. 

6.  Lockheed  Aeronautical  Systems  Company,  "Avionics  Bus  Interface  Module,"  Dwg.  No.  50R5048, 27  March  1987. 

7.  Collins  Government  Avionics  Division,  Rockwell  International,  "High  Speed  Data  Bus  SystemSpecification,”  prepared  for  Pave 
Pillar  program  Office,  Document  No.  10-03,  Version  3,  Contract  No.  F33615-83-C-1036, 31  October  1986. 

8.  Nelson,  J.H.,  etal.,  "A  Candidate  for  Linear  Token-Passing,  High-Speed  Data  Bus  Systems,"  Presented  to  the  SAE  Aerospace 
Systems  Division  Meeting,  Dallas,  TX,  4  November  1987. 

9.  Standardization  (NATO)  Agreement  (STANAG),  "High  Speed  Data  Transmission  Under  STANAG  3838  or  Fibre  Optic 
Equivalent  Control,"  STANAG  3910,  Rev.  1.3, 27  August  1987. 

10.  IBM,  Honeywell,  and  TRW,  "VHSIC  Phase  2  Interoperability  Standards:  Pi-Bus  Specification,"  Version  2.0,  8  September 
1986. 

1 1.  Snow,  J.C.,  "A  User  Protocol  for  a  Fiber-Optic  High-Speed  Serial  Data  Bus,"  Proceedings  IEEE  1987  National  Aerospace  and 
Electronics  Conference,  NAECON  1987,  IEEE  87CH24J0-5,  Vol  1,  pp.  188-191,  May  1987. 

12.  Uhlhont,  R.W.,  "Design  of  a  Passive  Star-Coupled  Fiber  Optic  High  Speed  Data  Bus  for  Military  Aircraft,”  Proceeding  IEEE 
1987  National  Aerospace  and  Electronics  Conference,  NAECON  1987,  IEEE  87CH2450-5,  Vol.  1,  pp.  158-164,  May  1987. 

13.  Kawasaki,  B.S.,  and  K.O.  Hill,  "Low-loss  Access  Coupler  for  Multimode  Optical  Fiber  Distribution  Networks,"  Applied 
Optics,  Vol.  16,  No.  7,  pp.  1794-1795.  July  1977. 

14.  Piessey  Product  Data  Sheets  for  type  CXL044  and  CXL061  Light  Emitting  Diodes,  Plessey  Research  Ltd.,  Caswell,  England. 

15.  Olshansky,  R.,  "Propagation  in  Glass  Optical  Waveguides,  "Rev.  Mod.  Phys.,  Vol.  51,  pp.  341-367,  April  1979. 

16.  Gloge,  D.,  "The  Optical  Fibre  as  a  Transmission  Medium,"  Rpts.  Prog.  Phys.,  Vol.  42,  pp.  1777-1824,  November  1979. 

17.  Rawson,  E.G.,  and  Bailey,  M.D.,  "Bi-taper  Star  Couplers  with  up  to  100  Fibre  Channels,"  Electronic  Letters,  Vol.  15,  No.  14, 
pp.  274-275,  1978. 

18.  Williams,  J.C.,  and  Me  Duff ee,  F.T.,  "An  Engineering  Guide  to  Couplers,  ”  Fiberoptic  Technology,  pp.  129-134,  October  1981. 

19.  Graham,  DX,  private  communication. 

20.  Mac  Lean,  J.R.  and  R.  W,  Uhlhom,  "Physical  Layer  Considerations  for  a  High  Throughput,  Fiber  Optic  Serial  High  Speed  Data 
Bus,”  Proceedings  IEEE  1986  National  Aerospace  and  Electronics  Conference,  NAECON  1986,  IEEE  86CH2307-7,  Vol.  1,  pp. 
146-150,  May  1986. 

2 1 .  Smith,  R.G.  and  S.D.  Personick,  "Receiver  Design  for  Optical  Fiber  Communication  Systems,"  Chapter  4  in  Vol.  39,  Topics  in 
Applied  Physics,  SemjconAi,-i<ir  Devices  for  Optical  Communication.  H.  Kressel,  Editor,  Sptinger-Vetlag,  New  York,  1982. 

22.  Uhlhom,  R.  W.  "A  Robust  Fiber  Optic  Active  Star  Coupler  for  the  SAE  Linear  Token-Passing  Multiplex  Data  Bus,"  presented  at 
the  National  Aerospace  and  Electronics  Conference,  NAECON  1988,  Dayton,  OH.,  May  1988. 

ACKNOWLEDGEMENT 

The  author  wishes  to  thank  Mr.  John  Ostgaard  of  the  U.S.  Air  Force  Avionics  Laboratory,  and  AGARD,  for  the 

opportunity  to  participate  in  this  lecture  series.  All  original  work  reported  in  this  paper  was  sponsored  by  the  Harris  Corporation 

Independent  Research  and  Development  program.  Messrs.  F.T.  Couey,  J.B.  Pearce,  P.A.  Winkclman,  and  P.J.  Rossana  of  the 

Harris  Corporation  have  been  particularly  helpful  and  encouraging  while  preparing  for  the  series.  I  would  like  to  thank  Mr.  J.C. 

Snow  for  permission  to  use  his  description  of  the  parallel  internal  bus. 


8-1 


HIGH  SPEED  PARALLEL  PROCESSING 
NETWORKS  FOR  ADVANCED  ARCHITECTURES 

D.  REED  MORGAN 

U.S.  AIR  FORCE  WRIGHT  AERONAUTICAL  LABORATORIES 
AVIONICS  LABORATORY 

WRIGHT-PATTERSON  AIR  FORCE  BASE,  OHIO,  U.S. A.  45433 
SUMMARY 

Many  force  Multiplier  improvements  in  vehicle  control,  situation  awareness  and  crew  decision  aiding  will 
be  nade  possible  if  affordable,  flysble  supercomputers  and  associated  software  can  be  developed  for 
next-generation  military  aircraft.  New  functional  architectures  will  emerge  because  dramatic 
Improvements  in  processing  speed  can  ba  Implemented  through  tightly  coupled  networks.  Unconstrained 
system  architectures  csn  be  developed  where  the  system  designer  will  have  the  capability  to  fuse  together 
needed  logical  functions  irrespective  of  previous  boundaries.  In  addition,  increased  local  processing 
(e.g.,  "smart"  sensors)  will  be  made  possible  to  Improve  threat  and  target  classification.  Robust  u6e  of 
real-time  artificial  intelligence  at  both  local,  functional  and  system  levels  will  be  achievable,  along 
with  Improvements  in  fault  tolerance  and  system  diagnostics. 

Avionics  supercomputer  networks  are  expected  to  be  used  by  the  early  21st  century  to  Implement 
metafunction  integration.  For  example,  an  Integrated  vehicle  control  bystem  metafunction  will  be  made 
possible.  Several  previously  separate  functions  such  as  propulsion  controls  (engine  and  thrust 
vectoring),  flight/guidance  controls,  navigation  equipment,  fire  control  and  weapons  control  can  be 
cloeely  tied  together  to  accomplish  optimum  maneuvers  for  Improved  survivability,  fuel  economy,  weapon 
delivery  effectiveness  and/or  fault  tolerance.  Other  metafunctions  may  evolve  wlthln/across  the 
electro-optical  sensor  spectrum,  the  radio  frequency  spectrum,  the  pilot-vehicle  Interface  function  and 
system-level  decision  aiding  using  machine  intelligence  (e.g.,  tactics  and  real-time  mission  planning). 

Computer  speed  Improvements  of  the  order  of  100-1000  times  that  of  the  fastest  avionic  compatible 
processors  available  today  Is  needed  for  data,  signal  and  artificial  Intelligence  processing.  Only 
parallel  (i.e.,  concurrent)  processing  can  potentially  achieve  these  needed  speed  improvements. 

This  paper  describes  various  parallel  processing  architecture  network  that  are  candidates  for  eventual 
airborne  use.  An  attempt  at  projecting  which  type  of  network  is  suitable  or  optimum  for  specific 
metafunction  or  stand-alone  applications  is  made.  However,  specific  algorithms  will  need  to  be  developed 
and  bench  marks  executed  before  firm  conclusions  can  be  drawn.  Also,  a  conceptual  projection  of  how 
these  processors  can  be  built  in  small,  flysble  units  through  the  use  of  wafer  scale  Integration  is 
offered.  The  use  of  the  PAVE  PILLAR  system  architecture  to  provide  system  level  support  for  these 
tightly  coupled  networks  Is  described. 

The  basic  conclusions  to  be  drawn  from  this  paper  are:  (1)  extremely  high  processing  speeds  Implemented 
in  flysble  hardware  is  possible  through  parallel  processing  networks  if  development  programs  are  pursued, 
(2)  dramatic  speed  enhancements  through  parallel  processing  requires  an  excellent  match  between  the 
algorithm  and  computer  network  architecture,  (3)  matching  several  high  speed  parallel  oriented  algorithms 
across  the  aircraft  system  to  a  limited  set  of  hardware  modules  may  be  the  most  coat  effective  approach 
to  achieving  speed  enhancements,  and  (4)  software  development  tools  and  Improved  operating  systems  will 
need  to  be  developed  to  support  efficient  parallel  processor  utilization. 

INTRODUCTION 


The  motivation  to  consider  the  use  of  parallel  processing  can  be  grasped  by  pondering  the  operation  of 
the  brain.  Dr  V.  Daniel  Hlllls,  Inventor  of  the  Connection  Machine  (a  massively  parallel  network 
processor)  hae  phrased  the  question  as  follows:  "how  can  the  brain  take  an  unstructured,  complex  problem 
and  deduce  the  answer  in  a  fraction  of  a  second,  whan  a  "smart"  computer  ma^  take  hours  or  days  to 
perform  the  operation?  Why  la  the  computer  so  stupid  when  It  could  have  10  more  switch  changes  per 
second  than  the  brain?"  Dr  Hlllls  suggests  that  the  answer  lies  with  the  brelns  massively  parallel 
operation  where  an  array  of  self-organizing,  fault  tolerant  neurons  perform  possibly  100  steps  of 
processing  actions.  [1]  The  concept  of  concurrently  using  many  processors  to  solve  complex  problems  in  s 
"divide  and  conquer"  strategy  appears  to  ba  the  only  approach  for  real  time  operation.  Researchers  are 
currently  attempting  to  partially  emulate  the  operation  of  the  brain  in  an  exciting  new  field  called 
neural  networks  and  someday,  adaptable  learning  systems  may  be  possible.  However,  we  must  generally  be 
content  In  working  with  processors  having  much  larger  grain  size  than  the  neuron.  As  will  be  seen,  the 
choice  of  the  grain  else  depends  on  many  factors  including:  (a)  the  degree  to  which  the  algorithm  can  be 
parallelised  (b)  the  complexity  of  the  resulting  network  and  switches  (c)  software  control  complexities 
and  (d)  fault  tolerance  of  the  resulting  network. 

Impressive  processing  speed  improvements  have  been  recently  achieved  through  the  use  of  Very  High  Speed 
Integrated  Circuit  (VHSIC)  technology.  For  example,  a  3  million  instructions  par  second  (DAIS  mix) 
processor  with  256K  words  of  memory  in  about  a  6"x6"x.6  (15cm  x  15cm  x  1.5cm)  package  has  been  built 
under  the  PAVE  PILLAR  program  et  WPAFB,  Ohio.  Teeter  processors  (approximately  5  times)  will  be  made 
possible  by  the  second  phase  of  the  VHSIC  program.  During  the  early/mid  1990a,  we  will  be  reaching  speed 
limits  on  how  faat  a  given  microcircuit  can  process  data  dua  to  Inherent  limitations  on  the  feature  size 
of  chip  componentry.  And  although  these  Incredible  speeds  will  be  exploited  across  an  array  of  military 
systems,  dramatically  fester  (e.g.,  100  times)  processing  will  etlll  be  required  for  certain 
applications.  If  these  algorithms  were  Implemented  today,  they  could  only  be  investigated  on  the  ground 
since  e  large  supercomputer  would  be  required.  If  we  limit  oureelvee  to  a  smaller  claaa  of  avionic 
problems  end  ere  able  to  partition  tha  algorithms  properly,  the  possibility  exists  that  we  can  achieve 
the  needed  epeede  In  flysble  configurations  by  using  an  array  of  procesaora  Implemented  through  advanced 
microcircuitry. 
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Several  government  sponsored  and  commercial  ventures  have  led  to  the  development  of  ground-based  parallel 
networks  that  have  been  demonstrated  as  operating  faster  than  classical  supercomputers.  However,  these 
machines  are  still  much  too  large  for  airborne  use  and,  invariably,  their  speed  superiority  against  say 
the  CRAY  X-MP  {Cray  is  a  trademark  of  Cray  Research  Inc.,  Minneapolis,  Minn.,  USA.)  is  limited  to  one  or 
a  few  special  algorithms  which  uniquely  match  its  special  network  architecture. 

Although  the  concept  of  exploiting  parallelism  appears  to  be  the  way  we  should  proceed  for  high  speed 
airborne  processing,  two  radical  design  features  will  need  to  be  incorporated  to  achieve  affordable  and 
flyable  hardware.  These  design  features  are:  (1)  processors,  memories  and  Input/output  functions  will 
need  to  be  Implemented  in  microcircuitry  at  the  wafer  level  In  order  to  achieve  needed  site  reduction. 
This  capability  appaara  achievable  by  the  mid  1990a,  based  on  current  research.  Using  wafer  scale 
integration,  extremely  powerful  (end  highly  reliable)  circuits  can  be  built  using  several  high  speed 
processing  cells  interconnected  on  a  4"  (around  10  cm)  wafer.  These  wafers  can  then  be  stacked, 
achieving  e  "three  dimensional"  computer  (advanced  cooling  techniques  may  be  required),  (2)  the  high  cost 
of  both  hardware  and  software  associated  with  parallel  machines  Implies  that  we  must  avoid  unnecessary 
proliferation  of  basic  processor  architectures.  The  goel  would  be  to  develop  a  family  of  common,  modular 
wafers  for  replicated  use,  with  advanced  CAD/CAM  techniques  employed  to  reduce  cost.  However,  we  must 
"personalize"  the  network  architecture  to  match  the  parallelized  algorithm.  Therefore,  either  the 
network  topology  of  wafer-based  parallel  processors  need  to  be  programmable ,  or  a  limited  number  of 
different  (modular)  wafers  will  need  to  be  mixed  together  in  the  stack  In  order  to  achieve  the  desired 
speeds.  Both  techniques  may  have  to  be  used  for  some  applications.  An  exploratory  development  study  1b 
underway  within  the  Avionics  Laboratory  to  identify  the  best  design  approaches. 

Several  different  parallel  implementations  are  currently  available  to  permit  designers  to  match 
applications  with  parallel  architectures.  Usually,  the  designer  will  be  required  to  trade  off  the 
complexity  (and  cost,  weight  and  power)  of  the  communication  topology  between  the  processor  nodes  and  the 
cost  of  replicating  tha  processor  nodes.  For  example,  the  designer  might  choose  a  small  number  of  "large 
grained"  nodes  (having  sxpenalve  processors  and  memories)  but  poaaasslng  a  low-cost  interconnection 
network.  On  the  other  hand,  he  might  want  to  investigate  the  use  of  a  robust  set  of  "fine  grained" 
(having  low  cost  processors  and  memories)  and  a  costly  data  distribution  network.  In  most  esses  however, 
the  characteristics  of  the  application  algorithm  will  be  the  major  determining  factor  In  selecting  major 
architectural  features. 

New  software  tools  and  languages  are  now  being  developed  to  support  parallel  network  development.  These 
rools  include  compilers  that  parallelize  code  to  affect  a  more  efficient  architectural  match  before 
loading  the  program.  Also,  network  simulators  are  being  developed  that  aid  the  programmer  In 
understanding  and  debugging  the  code.  However,  the  field  of  parallel  processing  Is  so  dynamic  that 
often.  Immature  tools  and  operating  systems  lead  to  frustration  and  disappointing  results  (hastily 
designed  hardware  and/or  operating  ayetema  can  lead  to  systems  that  run  slower  as  more  processors  are 
added  to  the  network). 

It  is  important  that  we  collectively  assess  the  applicability  of  parallel  processing  to  military  aviation 
and  help  direct  its  development  to  achieve  performance  advancements  needed  in  the  early  21at  century. 

BACKGROUND 


Before  describing  the  array  of  architectural  choices  and  their  relative  application  benefits,  let  us 
first  look  at  why  the  classical  Von  Neumann  machine  does  not  Inherently  support  high  speed  processing. 
Figure  1  shows  a  simplified  version  of  such  a  processor.  Nota  that  tha  central  processing  unit  (CPU)  la 
the  single  locus  of  control  and  that  It  must  sequentially  (aerially)  fetch  data  and  programs  out  of 
memory  In  a  "single  thought  at  a  time"  mode  of  operation.  Note  that  as  a  consequence  of  this  design,  the 
overall  process  is  slowed  down  because:  (s)  control  or  data  signals  from  elsewhere  in  the  system  can 
Interrupt  CPU  operation,  (2)  the  CPU  experiences  a  "bottleneck"  in  attempting  to  accomplish  processing 
since  much  of  the  time  Is  spent  retrieving  and  storing  data  from  a  relatively  small  percentage  of  total 
memory  (l.e.,  only  1-2Z  Is  nominally  in  use  at  one  time). 

Although  faster  microcircuitry  can  be  used  to  speed  up  the  process,  a  practical  limit  on  processing  spe^d 
is  eventually  reached.  For  example.  Figure  2  shows  the  growth  In  speed  for  airborne  uniprocessors  over 
the  last  decade  and  a  projection  of  future  growth.  Figure  2  shows  the  speed  achieved  in  using 
MIL-STD-1750A  instruction  set  computers  executing  the  Digital  Avionics  Information  System  (DAIS) 
Instruction  mix.  Note  that  as  the  minimum  feature  size  of  the  microcircuit  has  been  reduced  over  time, 
tha  use  of  increased  clock  rates  result  In  higher  processor  throughputs.  However,  a  practical  limit  on 
featura  slza  (at  around  0.25  -  0.5  micron)  leads  to  an  attendant  limit  on  clock  rate  (around  100  MHz), 
forcing  tha  computer  architect  to  resort  to  Reduced  Instruction  Set  Computers  (RISC)  in  or*er  to  achieve 
further  speed  gains  (l.e.,  only  simple  Instructions  are  implemented  In  hardware  with  RISr  machines  -  they 
would  not  be  efficiently  used  for  algorithms  requiring  extensive  complex  operations  atrch  as  floating 
point).  In  order  to  achieve  higher  speeds,  the  designer  can  choose  a  large  number  of  rimple  "fine 
grained"  machines  on  one  end  of  the  spectrum  or  a  smaller  number  of  "coarse  grain"  an  : bines  at  the  other 
end,  and  accomplish  parallel  procesalng.  All  avoidable  "chokepolnts"  or  process?  tnat  Inhibit  speed 
must  be  designed  out  of  the  system.  For  example,  attempting  to  use  the  same  mer jry  with  several 
processors  causes  a  memory  access  bottleneck.  We  must  design  parallel  ays terns  that  Inhibit  unnecessary 
I/O  Intarmpts,  minimise  and  remote  the  control  of  the  process  and  distribute  the  memory.  And  this  must 
be  done  In  such  a  way  to  allow  for  fault  tolarant  operation. 

Before  resorting  to  the  use  of  parallel  processing  to  achieve  the  needed  speed,  the  designer  should 
consider  the  applicability  of  various  single  processor  speed-up  techniques.  These  techniques  are  almad 
at  causing  a  larger  percentage  of  CPU  circuits  to  be  active  at  any  given  time.  (Thla  la  a  form  of 
"virtual"  parallel  proceeelng  in  that  concurrency  of  operation  is  achieved) .  One  approach  Is  to  use  a 
technique  called  memory  Interleaving  (If  appropriate  to  the  application).  Here,  large  erraye  of  number a 
are  stored  In  separately  accessible  memory  units  (ssy  8-16),  permitting  the  CFtJ  to  simultaneously  access 
each  unit  ovar  multiple  lines.  Further,  a  speed-up  concept  called  pipelining  may  prove  at tractive. 
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Her*,  the  calculation*  involved  depend  on  the  need  to  perform  several  small,  yet  different  steps  allowing 
a  section  of  the  CPU  to  perform  part  of  the  calculation,  pass  It  on  for  the  next  Independent  step  (l.e., 
pipeline),  while  simultaneously  bringing  in  new  dsta  for  processing.  Use  of  this  technique  to  accomplish 
vector  suit lpLlcat ion  of  state  values  is  comon.  Finally,  the  uae  of  very  long  word  processing  (up  to 
1024  bits /word)  is  s  means  to  speed  up  computing  by  simultaneously  executing  instructions  on  the  data. 
However,  care  must  be  exercised  In  scheduling  the  operations  to  avoid  dsta  dependencies. 

MULTIPROCESSING 


In  order  to  achieve  higher  speeds,  the  designer  must  eventually  resort  to  using  multiple  computers. 

Pigure  3  shows  the  range  of  "speed-up  factors"  to  be  expected  as  a  function  of  the  number  of  processors 
In  the  network.  Note  that  choke points  can  still  exist.  For  example,  the  lower  curve  shows  the  effects 
of  memory  access  and  pyatsm  control  bottlenecks  when  several  processors  attempt  to  share  a  comon  memory 
(this  is  not  consldtre d  to  be  a  true  parallel  processor  configuration).  Figure  3  also  shows  the  ideal 
case  using  parallel  processing  where  no  bottlenecks  occur  and  a  perfect  algorlthm-to-archltecture  match 
has  occurred.  In  between  these  two  boundaries  lies  the  practical,  raal-world  processor  speed  up  that  can 
be  achieved.  Hopefully,  about  85-90Z  of  the  ideal  speed  up  can  bs  achieved.  Tbs  shape  of  the  curve  will 
be  primarily  detsrmlned  by  the  relative  number  of  1/0  Interrupts  across  the  network,  the  length  of  time 
required  to  transmit  messages  between  processors  and  the  extent  of  memory  segmentation. 

Before  describing  the  operation  of  various  parallel  machines.  It  Is  worthwhile  to  remind  ourselves  of  two 
basic  considerations:  (1)  the  overall  network  must  possess  fault  tolerant  features  for  most  airborne 
applications  Involving  airborne  guidance  and  control  applications  and  (2)  the  system  operation  of  the 
parallel  processing  network  will  likely  be  controlled  by  another  computer  -  a  Von  Neumann  machine. 

PARALLEL  PROCESSING  SPEED  UP 


The  single-most  important  Issue  In  parallel  processing  Is  the  equivalent  speed  up  gained  by  the  use  of 
"n"  processors.  In  general,  a  speed  up  of  "n"  cannot  be  expected  since  real  world  problems  are  not 
perfectly  parallel  (l.e.f  requiring  an  algorithm  that  can  be  executed  on  multiple  processors  without 
communication  between  these  processors). 


In  general,  the  speed  up  fector  Sn  is  defined  as  Sn 


•r„ 


where  is  the  algorithm  execution  time 


required  for  one  processor  and  Tn  Is  the  execution  time  for  n  processors.  If  X  represents  the  fraction 
of  work  that  can  be  processed  in  parallel,  and  we  assume  that  at  any  inatant,  either  only  one  machine  Is 
working  or  all  n  of  them  are  working,  S(n,  A)-  1  <  for  all  n,  a  • 


(l- a)  I 

Here,  the  execution  time  of  one  processor  is  norms li*< 


Tl 


to  unity.  (3) 


Note  that  the  first  term  In  the  denominator  represents  the  fraction  of  the  algorithm  that  cannot  be 
parallelised  and  the  second  term  Is  the  time  required  to  execute  the  portion  that  is  parallellzeble. 
Figure  4  shows  a  plot  of  the  speed  up  factor  S  as  a  function  of  X  .  Figure  4  points  out  a  fundamental 
property  of  parallel  computation:  unless  X  is  greater  than  0.9,  parallel  networks  will  not  provide  a 
significant  speed  increase.  It  is  Imperative  that  the  algorithm  be  investigated  for  parallelism  before 
proceeding  to  parallel  network  Implementation.  Since  the  slope  of  the  curves  in  Figure  4  vary  as  a 
quadratic  relationship  with  n  as  Xy  approaches  1,  new  algorithms  emphasizing  parallelism  and/or  the  use 
of  compiler  tools  that  reformat  an  existing  algorithm  Into  its  moat  robust  parallel  form  may  be 
mandatory.  Given  that  an  algorithm  lends  itself  to  parallelism,  then  its  slgnlf Icsntly  parallel  portions 
must  be  efficiently  mapped  onto  the  proper  network  architecture  if  ’'real-time"  processing  of  complex 
algorithms  Is  to  be  achieved.  The  architecture  selected  must  exhibit:  (a)  the  proper  "grain  site"  for 
each  processing  element,  (b)  highly  efficient  common lest ions  between  processing  elements,  (c)  high  speed 
memory  accessablllty  (particularly  for  large  sited  applications),  (d)  good  load  balancing  for  the 
processing  tasks  over  time  and  (e)  real  time,  fault-tolerant  operation. 


In  swnaary,  an  efficient  parallel  processing  network  must  possess  a  processor  Interconnect  topology  and 
system  control  strategy  that  grows  weakly  with  increasing  n.  Examples  of  various  parallel  network 
topologies  are  presented  below. 


TERMS  USED  IN  PARALLEL  PROCESSING 


Before  proceeding  further,  a  few  terms  need  to  be  defined  to  aid  information  exchange. 

Perfectly  Parallel:  an  slgorlthm/parallel  network  application  that  Is  executed  on  multiple  processors 
without  communication  between  the  processors  [2]  (Perfectly  parallel  systems  are  an  artificial  conatnzct 
for  comparison  with  other  meaningful,  "real  world"  algorithm /network  realizations). 

Explicitly  Parallel:  an  algorithm/parallel  network  that  can  be  executed  on  multiple  processors  only  with 
communication  with  neighboring  processors.  (5]  (nearest  aalghbor  processing  la  particularly  useful  In 
comparing  parameters  for  fine  grain  network  applications). 

Host  Processor:  a  separate.  Von  Neumann-based  machine  used  to  control  the  operation  of  the  parallel 
network  (e.g.,  synchronization  of  nodes,  dsta  processor  routing,  control/dlstrlbutlon  of  dsts  from 
external  sensors,  etc.). 

Node:  a  processor /memory  pair  in  tha  network.  The  node  usually  contains  an  Input /output  auction  that 
racalves  Incoming  data  and  rentes  messages  and  data  to  other  nodes  and  could  conceivably  contain  a 
co-processor  for  special  purpose  applications.  The  associated  memory  may  be  directly  connected  to  the 
local  processor  or  allowed  to  be  jointly  addressed  by  the  local  processor  and  other  nodes  in  tha  network. 
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SIM)  (Single  Instructions  Multiple  Date):  a  single  Instruction  stream  network  control  concept  where  all 
processors  are  controlled  (by  the  host)  by  broadcasting  sequential  Blngle  Instructions  to  each  node. 
Typically,  each  processor  has  the  option  of  executing  each  Instruction  or  Ignoring  It,  depending  on  the 
Internal  state  of  the  processor. 

MIMD  (Multiple  Instruction  Multiple  Data):  a  multiple  Instruction  stream  network  consisting  of  a 
collection  of  connected  autonomous  nodes,  each  capable  of  executing  their  own  programs.  A  loose 
mechanism  for  synchronizing  operations  between  nodes  usually  Is  employed. 

Note:  It  la  possible  to  use  a  SIMD  and  MIMD  network  to  emulate  the  other  with  various  degrees  of 
complexity  and  overhead  software  for  control.  Either  network  approach  can  be  used  for  virtually  any 
application  -  differences  in  performance,  cost  and  complexity  must  be  addressed  however. 

Availability  of  Prototype  &  Commercial  Parallel  Processors 

In  order  to  obtain  Inalght  Into  the  types  of  parallel  processing  machines  which  need  to  be  Investigated 
for  airborne  applications,  see  Table  1  which  shows  a  partial  list  of  various  machines.  (The  total  number 
of  parallel  processor  models  developed  will  likely  reach  100  by  1990  with  over  30  vendors).  Referring  to 
Table  1,  It  can  be  seen  that  vendors  have  chosen  to  implement  these  machines  with  different  topologies. 
Interconnecting  vastly  different  numbers  and  types  of  processors.  Application  guidelines  from  the  proper 
selection  of  these  various  network  architecture  features  will  be  addressed  below.  The  reader  is  reminded 
that  chase  machines  are  designed  for  ground-based  operation  for  scientific  and  engineering  applications. 
Extensive  size  reduction  must  he  accomplished  for  airborne  applications. 

Candidate  Architectures 


In  discussing  digital  processing  architectures ,  it  is  important  to  differentiate  the  system  architecture 
used  to  integrate  aircraft  functional  elements  and  the  parallel  processing  network  architecture. 

System-Level  Topology 

The  PAVE  PILLAR  System  architecture  provides  s  physical  and  logical  means  of  Integrating  and  controlling 
functions.  Its  high  speed  data  bus,  token  passing  protocol  and  the  Ada-based  operating  system  allows  the 
designer  great  flexibility  In  integrating  processing  resources  and  sensors  (e.g.,  flight  control  system), 
signal  processing  functions  (e.g.,  coupling  of  coneion  signal  processors  for  fault  tolerance  purposes)  and 
the  overall  system-wide  Integration  of  flight  control,  avionics,  weapons,  sensors,  displays,  etc.  The 
reader  will  note,  from  Pigure  5,  that  PAVE  PILLAR  is  a  parallel  processing  system  of  computing  resources 
communicating  over  a  bus-driven  interconnection  network.  It  is  not  generally  appreciated  that  military 
avionic  architectures  have  been  supporting  parallel  network  operation  since  the  mid-1970s  (the  author  Is 
aware  of  the  DAIS  nysteo  being  introduced  in  this  time  frame).  The  motivation  behind  such  networks  was 
driven  by  the  absolute  requirement  for  real-time  computation  (hence,  partitioning  functions  to  different 
computers).  However,  the  already  established  avionic  engineering  disciplines  and  functional  partitioning 
necessitated  by  the  earlier  use  of  hard-wired,  analog-baaed  avionics  further  ensured  that  separate 
functionally-driven  processing  would  be  used  when  more  flexible  digital  processing  and  multiplexing  were 
introduced  In  aircraft. 

Multiplex  bus-driven  architectures  possess  the  best  features  for  integrating  loosely  coupled  networks  of 
processors  (i.e.,  ease  of  integratdon/retrof it,  fault  tolerance,  eaae  of  system  control).  Time  delays 
such  aa  bus  latencies  caused  by  bus  control  protocols  or  processor  Interrupts  by  executive  control  are 
usually  not  significant  problems  for  this  class  of  applications. 

However,  once  we  must  resort  to  accomplishing  high  speed  domain-based  parallel  processing  (i.e.,  within  a 
specific  function)  that  requires  many  tightly  coupled  processors  to  accomplish  the  task  In  real  time,  a 
bus  oriented  design  may  be  found  to  be  Inadequate  for  inter-node  connectivity.  Notice  however,  that  the 
bus  approach  will  still  be  useful  In  Integrating  separate  parallel  processing  networks.  Referring  again 
to  Figure  5,  the  reader  can  visualise  that  the  basic  PAVE  PILLAR  architecture  could  potentially  support 
the  use  of  tightly  coupled  parallel  networks  at  virtually  every  possible  level.  Por  example,  such  a 
network  could  be  used  within  a  particular  signal  processor  to  perform  special  signal  analysis  or  within  a 
sensor  or  weapon.  Further,  a  parallel  network  responsible  for  high  level  system  management  functions 
could  be  connected  to  the  mission  avionics  bus.  Finally,  we  could  consider  using  a  combination  of 
parallel  networka  and  PAVE  PILLAR  networka  or  buses  to  create  higher  levels  of  more  closely  coupled 
functions. 

Why  do  we  need  dramatically  higher  speeds  on  future  aircraft? 

Future  aircraft  processing  avionics  systems  must  provide  dramatic  performance  Improvements  In  two  basic 

areas: 

(1)  Vehicle  system  control  Integration  to  achieve  improved  control,  energy  maneuverability  and  fault 
tolerance  for  enhancements  in  survivability  and  weapons  delivery. 

Thla  will  require  the  coupllng/coordlnation/lntegratlon  of  engine  controls,  thrust  vectoring  (where 
applicable),  flight  control,  navigation  and  guidance  functions,  fire  control  and  weapons  control.  With 
this  propulalon/f llght/guldance/f ire  control  synergy,  aircraft  should  be  able  to  perform  more  effective 
maneuvers  to  evade  missiles,  out-maneuver  enemy  aircraft  for  favorable  attack  conditions.  Improve 
survivability  against  heavily  defended  ground  targets  through  maneuvering  attack,  minimise  fuel 
consumption,  ate. 

Such  an  Integrated  system  will  require  a  robust  use  of  high  speed,  fault  tolerant  networks  to  perform 
artificial  Intelligence  reasoning  for  optimum  control  and  reconfiguration  strategies  and  to  manipulate 
large  arrays  of  matlcea  describing  control  coupling  affects. 
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(2)  Improved  situation  awareness  of  enemy  and  friendly  forces  in  complex,  dense  and  rapidly  unfolding 
environments  will  require  the  use  of  nultlspectrel  sensor  integration  end  coordination,  automatic  target 
and  threat  recognition,  development  of  pilot  decision  aiding  tactics  and  recommendations,  reduction  of 
excessive  date  for  presentation  and  the  generation  of  distilled  information.  These  processes  in  turn 
require  orders  of  magnitude  improvements  In  signal  and  image  processing  speeds  and  artificial 
intelligence  processing. 

In  achieving  both  of  the  above  capabilities,  we  can  expect  the  pervasive  use  of  machine  intelligence  from 
the  sensor  level  up  through  the  system  level.  Because  of  the  need  to  fuse  and  control  functional 
information,  we  can  expect  a  trend  towards  Integrated  metafunctlona  (i.e.,  collection  of  functions).  For 
example,  the  integrated  vehicle  control  function  described  above  may  be  eventually  implemented  as  s 
closely  integrated  aet  of  vehicle  and  trajectory  control  functions.  Further,  the  merger  of  electronic 
warfare,  cowninlcatlona  and  radar  functions  may  evolve  into  an  integrated  Radio  Frequency  (RF) 
metafunction.  At  tha  highest  system  level,  a  decision  aiding  metafunction  to  recotmnend  overall  tactics 
and  mission  plans  may  emerge.  Advanced,  high  speed  parallel  networks  will  be  needed  to  not  only  provide 
the  necessary  sensor-level  processing  within  the  matafunction,  but  tha  network  will  likely  be  used  to 
Integrate  the  separate  functions  within  the  metafunctlon.  It  Is  the  suthor's  view  that  the  metafunction 
processing  sites  would  in  turn  be  Integrated  through  a  high  speed  bus  structured  network  (i.e.,  PAVE 
PILLAR). 

PARALLEL  NETWORK  CANPIDATE  TOPOLOCI ES 


This  section  addresses  the  various  nodal  interconnection  techniques  that  the  designer  may  wish  to 
consider.  A  general  description  of  several  network  topologies  will  be  presented,  along  with  a  discussion 
of  currently  available  networks  that  reflect  that  topology.  Although  the  examples  will  only  touch  on  a 
portion  of  the  available  networks,  they  are  representative  of  the  choices  presented  to  the  designer.  The 
failure  of  most  parallel  processing  algorithms  to  scale  properly  for  applications  requiring  more  than  a 
few  processors  is  usually  attributed  to  the  glut  of  communications  (i.e.,  the  interconnection  scheme  was 
poorly  designed).  (4] 

CIRCUIT  SWITCHED  NETWORK  TOPOLOGIES 


*he  circuit  switched  network  is  the  simplest  approach  to  Interconnecting  nodes  if  their  number  is 
relatively  small  (e.g.,  under  20)  and  inter-nodal  communication  la  noe  erratic.  Figure  6  shows  a  circuit 
switch  approach  that  has  non-adaptive  message/data  routing  (i.e.,  the  path  of  the  message  between  nodes 
depends  solely  on  Its  source  and  destination).  This  type  of  switch  is  similar  to  telephone  network  where 
a  node-node  link  is  established  and  held  as  long  as  needed.  This  approach  simplifies  control  problems 
(e.g.,  simple  software),  but  could  he  inefficient  If  the  applications  requires  highly  dynamic  message 
passage. 

This  type  of  switch  is  used  by  the  common  signal  processor  (CSP)  as  its  switching  architecture.  (Figure 
6)  Note  that  no  real  restrictions  have  been  placed  on  the  nodes  in  Figure  6.  There  could  be  floating 
point  processing  elements,  memory  elements,  a  fine  grained  parallel  processor  network,  a  data  processor 
or  a  combination  of  these  units.  In  fact,  a  major  attribute  to  the  circuit  switched  approach  is  its 
flexibility  and  simplicity  in  accomodating  different  kinds  of  nodal  processing  that  need  to  be 
Integrated.  The  CSP  design  allows  the  ultimate  in  hardware  flexibility  by  building  common  nodal  modules 
(including  the  switch  Itself)  for  easy  Insertion  into  a  common  Interconnect  backplane.  However,  the  main 
limitation  of  the  circuit  switch  is  that  the  complexity  (weight,  volume,  etc.)  grows  as  the  square  of  the 
number  of  nodes.  Hence,  doubling  the  number  of  processor  nodes  leads  to  four  times  the  number  of 
switched  ports.  Therefore,  for  large  networks,  this  technique  becomes  unacceptable. 

PACKET  SWITCHED  TOPOLOGIES 


Packet  switching  allows  nodes  to  communicate  through  addresses,  where  new  routes  are  established  each 
time  a  line  la  established  (i.e.,  similar  to  a  post  office  network).  These  networks  cen  be  used  for 
shared  memory  access  (i.e.,  to  permit  one  processor  node  with  its  local  memory  to  access  any  other  memory 
In  the  network)  or  to  transmit  data  or  commands  to  other  nodes. 

Shared  Memory  Switching 

Shared  memory  switching  is  a  subset  of  the  packet  switching  topology  and  supports  applications  where 
there  is  s  random  distribution  of  data  which  requires  access  by  individual  nodes.  Figure  7  shows  a 
simplified  example  of  a  small  (limited)  access  shared  memory  switch. 

The  features  of  such  a  network  can  be  better  understood  through  a  description  of  the  Butterfly  Parallel 
Processor.  ("Butterfly"  Is  a  trademark  of  Bolt,  Beranek  and  Nswman,  Inc.,  Cambridge,  HA,  USA), 

Collectively,  the  memory  of  the  nodes  forms  the  memory  of  the  entire  machine,  with  the  Butterfly  switch 
to  used  make  remote  accesses.  Typically,  local  memory  referencing  within  .*  node  takes  about  2 
microseconds  whereas  remota  accessing  may  take  5-6  microseconds.  The  system  la  currently  configured  with 
up  to  256  (HIM))  processor  nodes,  each  consisting  of  Motorola  66000  chip,  1-4  megabytes  of  memory,  a 
memory  management  unit,  and  a  processor  node  controller.  Each  node  ia  capable  of  executing  500,000 
Instructions  per  second.  The  bandwidth  through  each  processor  path  is  32  megablts/sec  -  thus  a  256  node 
machine  has  a  raw  processing  power  of  128  HIPS,  256  -  1024  MBytes  of  memory  and  an  interprocessor 
communication  capacity  of  8  gigabits /see .  Because  there  is  not  a  serious  performance  penalty  to  access 
remota  data,  tha  user  can  organise  data  without  serious  concern  over  where  it  is  located.  Nearly  linear 
speedup  hae  been  observed  for  large  complex  matrix  manipulations  and  large  configurations  are  being  used 
for  image  processing  and  computer  vision.  (5? 

The  uniqueness  to  the  Butterfly  stems  from  its  switch  (often  referred  to  as  a  Ban yon  awitch)  which  allows 
every  node  to  link  together.  Tha  number  of  switches  In  the  network  only  increases  as  n  log  ^n  (as 
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compared  with  n2  for  Che  crossbar).  For  s  100  node  Bystem,  the  Butterfly  switches  would  require  about 
500  wires,  compared  to  5000  for  a  cross  bar  system. 

The  topology  of  the  switch  Is  similar  to  that  of  the  Fast  Fourier  Transform  Butterfly  -  hence  the  name. 

A  simplified  view  of  the  switch  for  a  16  node  arrangement  is  shown  in  Figure  8.  Each  switch  is  a  4 
Input,  4  output  unit  custoa  chip.  Each  node  uses  packet  addressing  to  route  the  packet  from  the  source 
to  a  destination  node.  To  send  a  message  froa  node  5  to  node  14,  node  5  builds  a  packet  containing  the 
address  of  node  14  (1110  binary)  followed  by  the  message  data.  The  sending  switch  strips  off  the  two 
least  significant  address  bits  (10)  from  the  packet  and  uses  them  to  select  the  number  2  (10  binary)  port 
to  transmit  the  signal.  The  receiver  switch  strips  the  11  off  the  address  bit  to  switch  the  data  packet 
out  of  its  port  (11  binary)  to  processor  14.  Note  the  ingenious  arrangement  of  the  processors  relative 
to  the  switches.  Processors  2,6,10,14  (binary  0010,0110,1010,1110)  all  have  the  same  "10"  bits  In  the 
receiving  nodes  of  the  third  switch.  Similarly,  the  four  transmitter  switches  are  connected  to  the  third 
receiver  by  separate  "10"  lines.  Any  switch  can  issue  the  ”1110"  packet  and  be  linked  to  processor  14. 
These  switch  units  can  be  cascaded  both  horizontally  and  vertically  for  larger  networks.  Because  there 
is  a  not  a  dedicated  path  between  every  nodal  pair,  contention  can  occur  where  two  messages  can  reach  the 
same  node.  When  this  occurs,  one  message  Is  allowed  to  pass  with  the  other  being  retransmitted. 

Redundant  paths  are  implemented  for  fault  tolerance.  A  host  processor  is  used  to  edit,  link  and  compile 
data  and  programs.  (5) 

HYPERCUBE  TOPOLOGY 

The  hypercube  topology  Is  potentially  suited  for  applications  requiring  a  few  nodes  to  thousands  of 
nodes.  Each  node  operates  as  an  Independent  unit  which  can  communicate  while  processing.  Each  node  has 
its  own  memory  and  a  copy  of  Its  own  operating  systems.  Its  chief  benefit  may  lie  with  its  significant 
flexibility  since  it  is  a  superset  of  other  network  topologies.  Grid,  ring  and  tree  networks  can  be 
configured  by  programming  the  control  host  computer.  A  64  node  processor  hypercube  has  been  clocked  at 
twice  the  rate  of  a  Cray  X-MP  (although  the  average  speed  Is  only  one-fourth  the  speed  of  the  CRAY),  f 6 J 
Hypercubes  use  a  message  passing  approach  that  allows  nearest  neighbor  communications  from  one  node  to 
the  next  until  the  destination  node  Is  finally  reached  (with  intermediate  nodes  thereby  passing  on  the 
message).  The  dimension,  or  order  of  the  hypercuhe  Is  defined  as  the  maximum  number  of  Inter-nodal  links 
throughout  the  entire  cube.  Figure  9  shows  the  configuration  of  various  dimensions.  For  example,  if  the 
dimension  Is  3  (i.e.,  third  order  hygercube) ,  a  maximum  of  three  message  links  are  required  (average  of 
1.5)  and  the  number  of  nodes  being  2  »  8.  If  d  represents  the  cubes  dimension,  or  order: 

d  -  max  #  of  links 

2d  -  number  of  nodes 

d  -  time  average  of  number  of  links  (assuming  no 
2  contentions) 

n2d  -  number  of  (two  way)  connection  paths  between 
nodes 

For  example,  a  128  node  hypercube  would  be  of  order  7  and  require  7x128  -  896  communication  channels  (the 
programmer  needs  only  to  specify  the  nodes,  not  the  paths  taken,  however). 

The  power  of  the  hypercube.  In  addition  to  its  topology  flexibility,  lies  with  the  fact  that  the  number 
of  message  links  varies  linearly  with  d,  yet  the  number  of  total  processors  (a  measure  of  total  system 
speed)  goes  up  as  2  .  Thus,  a  six  cube  only  has  one  half  less  "hop"  on  average  than  a  7  cube  but  the  six 
cube  has  one-half  the  number  of  nodes.  However,  the  large  number  of  resulting  Interconnections,  as  the 
order  gets  larger,  can  prove  to  be  the  limiting  design  factor.  These  Interconnections  could  account  for 
the  majority  of  circuit  complexity,  weight  and  system  unreliability  and  can  result  in  data  latencies  due 
to  comminlcatlon  protocol.  A  goal  of  hypercube  design  Is  to  achieve  a  ratio  of  computation  time  to 
communication  time  of  about  10.  Load  balancing  may  also  prove  a  design  problem  for  certain  problems.  [2] 

The  Intel  Hypercube  from  Intel  Scientific  Computers,  Inc.,  of  Beaverton,  Oregon,  USA,  consists  of  two 
functional  elements  -  the  cube  and  the  cube  host  processor.  Units  containing  32,  68,  or  128  nodes  are 
available,  each  node  uelng  a  Motorola  80286  processor  and  512  kilobytes  of  local  memory. 

The  Connection  Machine  (Trademark  of  the  Thinking  Mechlnea,  Inc.,  Cambridge,  MA,  USA)  however,  represents 
one  of  the  most  robust  forms  of  parallel  processing.  This  design,  shown  Is  Figure  10,  consists  of  a 
massively  parallel  SIMD  network  having  a  maximum  of  65,536  nodes.  Each  node  consists  of  4096  bits  of 
memory,  a  message  router  circuit  and  a  one  bit  processing  unit.  The  host  can  control  Individual  nodes  or 
collections  of  nodes  to  achieve  virtually  any  type  of  calculation.  Algorithms  such  as  Image  processing 
or  semantic  nets  need  a  large  array  of  small  processors  and  are  particularly  suited  for  this  architecture 
class.  The  current  Connection  Machine  le  configured  in  a  1.4x1. 4x1. 6  meter  package.  It  is  capable  of 
one  billion  Instructions  per  second  (BIPS)  (for  a  32  bit  addition  benchmark)  and  has  demonstrated  6-7  PIP 
performance  In  Information  retrieval  applications.  This  machine  ban's  12th  order  hypercube  topology. 

The  Connection  Machine  can  be  programmed  to  emulate  a  M1MD  structure  but  Its  relative  efficiency  Is 
unknown.  Also,  since  each  node  cen  be  used  to  test  neighboring  processor  and  message  routers,  a  fault 
tolerant  communication  scheme  la  possible.  However,  the  resulting  complexity  of  this  approach  Is  also 
unknown .  f 1 ] 

SYSTOLIC  ARRAYS 

Systolic  arrays  capitalise  on  the  regular  structure  of  certain  algorithms.  The  term  "systolic"  refers  to 
the  pipelined  computations  that  are  scheduled  for  reuse  as  it  novas  through  the  array  and  draws  on  the 
comparison  of  ths  human  circulatory  system  (i.e.,  the  heart  aends  blood  through  the  circulatory  syatam  by 
fraquant  systolic  pumping  cf  small  amounts  of  blood).  Systolic  arrays  can  be  considered  es  e  cost 
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effective  approach  for  algorithms  having  a  large  Input  (or  output)  bandwidth.  Inputs  enter  the  array 
under  the  overall  control  of  a  boat  computer  (see  Figure  11).  The  data  is  sequentially  acted  on  in  a 
periodic  SIM)  Banner  as  it  moves  throughout  an  array  or  a  series  of  processing  elements.  Although 
significant  speeds  have  been  achieved  using  only  a  modest  amount  of  hardware  (for  properly  matched 
algorithms),  debate  continues  as  it  the  general  purpose  nsture  applicability  of  aystollc  arrays.  It 
appears  particularly  suitable  for  high  speed  Image  processing,  signal  processing  and  for  matrix 
arithmetic.  It  appears  that  fault  tolerance  can  ba  achieved  through  the  use  of  backup  sparing,  f 7 ] 
However,  concern  exists  as  to  whether  near  real  time  reconfiguration  can  take  place.  (8] 

OBSERVATIONS  ON  SELECTING  PARALLEL  NETWORKS 


The  coat  effective  choice  of  using  a  SIMD  or  HIM)  network  architecture  depends  on  the  characteristics  of 
the  application. 

In  general,  the  STMD-based  network  is  preferable  when  the  algorithm  is  well  structured,  and  has  a  regular 
pattern  of  control  for  the  cooperating  nodes.  If  the  algorithm  displays  these  properties,  the  network 
control  hardware  that  issues  the  highly  synchronised  single  Instruction  stream  can  be  shared  by  all 
nodes,  which  also  will  result  In  simpler  software  programing.  Example  algorithms  that  generally  possess 
these  properties  Include  matrix  calculations,  certain  types  of  artificial  intelligence  applications 
(s.g. ,  semantic  networks),  image  processing  and  signal  processing. 

A  MIMD  network  architecture  will  likely  be  preferred  if  the  algorithm  control  flow  is  highly  complex  and 
data  dependent.  For  such  algorithms,  much  of  the  SIMD  network  nodes  would  sit  idle  much  of  the  time 
waiting  for  the  proper  instruction. 

Example  MIMD-orlented  algorithms  include  certain  types  of  artificial  intelligence  applications  (e.g., 
rule  based  knowledge  acquisition),  for  cooperating  expert  systems  (e.g.,  tactics  planning,  mission 
planning,  system  health  management,  situation  assessment)  and  executive/system  control  of  complex 
processing  sites. 

It  must  also  be  observed  that  a  mixture  of  the  SIMD  and  MIMD  architectures  may  be  the  preferred  design 
for  some  applications. 

Finally,  the  designer  must  also  address  the  type  of  computer  architecture  needed  st  the  node.  For 
symbolic  oriented  (l.e.,  A I  processing),  a  simple  instruction  set  computer  architecture  Is  needed.  For 
numeric  based  algorithms,  complex  floating  point  and  vector  processor  features  will  be  needed. 

OBSERVATIONS  ON  PROGRAMMING  PARALLEL  PROCESSORS 


Although  some  parallelizing  compilers  and  some  software  development  tools  are  available,  the  programmer 
of  parallel  computers  must  still  be  extremely  careful  in  matching  the  structures  of  the  algorithm  and 
architecture.  New  languages  and  more  extensive  tool  sets  are  being  developed,  but  until  they  are  matured 
and  prove  themselves,  the  programmer  must  remain  knowledgeable  of  the  machine  operation  and  have  intimate 
familiarity  with  the  algorithm.  The  programmer  must  carefully  divide  the  problem  Into  logically  separate 
pieces  that  will  execute  concurrently  and  then  determine  how  the  processors  should  communicate  to 
exchange  data  and  messages.  Hopefully,  the  programmer  will  be  able  to  choose  from  a  variety  of  machine# . 
This  section  provides  some  gross  observations  about  the  tradeoffs  needed.  Many  of  these  observations  are 
taken  from  Reference  9. 

The  prograoner  needs  to  first  understand  the  size  and  number  of  the  Iterative  loops  in  the  algorithms  for 
purposes  of  decomposition.  This  process  enables  the  programmer  to  determine  the  needed  granularity 
properties  of  the  network  (l.e.,  granularity  is  a  measure  of  the  extent  each  node  spends  in  processing 
versus  communication  between  nodes) . 

Coarse  grained  nodes  would  be  selected  if  relatively  long,  Independent  processing  segments  are  typical  of 
the  calculations.  Note  however,  that  the  overall  network  could  still  be  architected  as  a  "nodes  of 
nodes"  if  fine  grained  operations  were  required  within  a  "coarse  grained"  loop.  This  concept  is  shown  in 
Figure  12  which  shows  a  generalized  network  of  parallel  machines. 

If  a  fine  grained  application  is  Identified,  fever  instructions  will  be  executed  between  inter-nodal 
messages . 

At  opposite  ends  of  the  spectrum,  a  large  grained  algorithm  might  be  Implemented  by  a  few  coarse  grained 
computers  having  relatively  slow  coimnin  lest  ion  links  or  a  small  grained  algorithm  by  a  large  number  of 
swell  nodes  requiring  extensive  and  fast  conunlcatlon  links. 

Once  the  programmer  determines  the  algorithm  granularity,  he  then  must  select  the  beet  ..  pe  of 
Inter-nodal  communication.  This  selection  usually  Involves  one  of  three  approaches:  (1)  a  bus  structured 
approach  (for  a  limited  number  of  nodes),  (2)  shared  memory  or  (3)  message  passing.  The  first  option 
will  not  be  discussed  here  due  to  its  relative  high  exposure  in  general  avionics  (e.g.,  DAIS,  PAVE  PIU.AF 
bus  structures).  Shared  memory  networks  allow  data  stored  In  e  shared  memory  location  to  be  read  by  all 
other  nodee.  This  approach  requires  synchronization  of  the  nodes  for  purposes  of  writing,  reading  and 
posting  data.  The  reading  processor  la  then  allowed  to  access  information  with  minimal  operating  system 
intervention.  For  e  message  passing  approach,  the  specified  receiver  requests  transmitted  data  from  a 
specified  sender  and  waits  for  its  reception.  This  approach  has  Implicit  system  sychronlzatlon, 
potentially  allowing  simpler  programming.  Message  passing  overhead  may  become  excessive  and  needs  to  be 
analyzed  first,  possibly  through  simulation. 

However,  the  whole  question  of  selecting  the  proper  communications  network  la  also  clouded  by  the  issue 
of  load  balancing,  which  translates  to  an  Issues  of  complexity  for  the  host  computer  software  and  grain 
size.  For  example,  if  the  algorithm  is  partitioned  into  modules  having  fixed  but  different  processing 
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complexities,  processors  will  be  left  Idle  waiting  for  others  to  finish.  To  balance  the  load,  one  could 
go  to  smaller  modules  (if  possible),  leading  to  more  nodes  (less  efficiency  due  to  ineer-node 
communication).  Thus,  a  conflict  occurs  requiring  a  tradeoff  of  communication  link  cost  and  size  versus 
ease  of  programing. 

For  parallel  programs  that  employ  shared  memory  techniques,  the  subtasks  tend  to  be  more  tightly  coupled 
than  with  message  passing  techniques,  and  frequent  inter-node  communication  is  expected.  Dynamic  load 
balancing  Is  efficient  for  relatively  small  taBks.  In  using  message  passing,  the  programser  will  attempt 
to  reduce  Interprocesaor  communication  by  statically  partitioning  aubtaBks  close  together  even  at  the 
expense  of  load  Imbalances.  Rigidly  structured  applications  not  requiring  tight  subtask  coupling  would 
therefore  benefit  by  the  message-passing  approach  result  In  efficient  communications  [9]. 

As  can  be  seen  by  the  above  discussions,  matching  the  algorithm  to  the  architecture  to  achieve  efficiency 
while  minimizing  programming  complexity  and  achieving  a  hardware  design  that  Is  affordable,  will  often 
involve  a  complex  decision  process.  A  significant  Investment  in  computerized  simulation  tools  will  be 
needed  to  Intelligently  affect  the  best  (compromised)  overall  design. 

MILITARY  AIRBORNE  APPLICATIONS  OF  PARALLEL  NETWORKS 


As  threat  capability  increases,  crew  members  are  forced  to  operate  under  more  time  compressed,  stressful 
situations  where  they  are  faced  with  a  vast  array  of  data  relating  to  threat,  terrain,  aircraft  and 
weapons.  The  crew  Is  required  to  develop  Information  from  the  data,  assess  the  situation  and  act  quickly 
In  life-threatening  situations,  while  continuing  to  fly  the  aircraft.  Dramatic  Improvements  are  needed 
to  help  the  aircrew  understand  the  "big  picture"  through  improved  situation  awareness  from  sensors  and 
displays  and  more  automation  must  be  used  to  simplify  the  execution  of  his  intent.  Improving  situation 
awareness  and  simplifying  the  control  over  the  weapon  system  will  require  the  robust  use  of:  (a)  "smart 
sensors"  that  permit  the  automatic  recognition  of  threats  and  targets,  (b)  selective  fusion  of  sensory 
Information  to  Improve  confidence  In  threat/target  recognition,  particularly  In  dense  EV  environments, 

(c)  coupling  of  vehicle  functions  to  Improve  performance  and  fault  tolerance,  and  selective  automation  of 
guidance  and  control  functions,  (d)  crew  decision  aiding,  and  (e)  simplified  or 

distilled  presentation  of  only  significant  Information  to  the  aircrew.  Achieving  these  capabilities  will 
require  extremely  high  throughput  processing  throughout  the  weapon  system  for  real  time  signal 
processing,  heuristic  processing  and  data  processing.  In  some  Instances,  high  speed  uniprocessors  or  a 
small  number  of  bus-connected  processors  will  be  adequate.  In  other  areas,  we  must  resort  to  parallel 
networks  to  achieve  the  needed  speeds.  The  following  discussion  provides  some  Insight  Into  the 
characteristics  of  some  of  these  high  speed  applications. 

SIGNAL  AND  IMAGE  PROCESSING 


Programmable  signal  processing  Is  currently  being  utilized  for  EW,  radar  and  CNI  airborne  applications. 
This  capability  has  allowed  highly  versatile  sensor  moding,  fault  tolerance  and  flexibility. 

The  author  expects  a  continued  escalation  of  the  use  of  avionic  sensors  requiring  very  high  speed 
processing.  Examples  include,  (1)  real  time  high  resolution  synthetic  aperture  radars,  (2)  low  ground 
speed  moving  target  indication  by  radar,  (3)  automatic  targat  recognizers,  (4)  versatile  beam  steering 
and  shaping  of  RF  signals  for  signal  transmission  and  reception,  (5)  terrain  following/terrain 
avoidmncm/ obstacle  avoidance  sensing  and  (6)  detection  of  signals  In  Jamlng  environments.  Image 
processing  applications  such  as  automatic  target  recognition  can  require  upwards  of  about  four  billion 
operations  per  second.  Upwards  of  5  billion  complex  operations  per  second  may  be  required  for  these 
applications.  Tn  general,  the  above  signal  processing  applications  will  require  matrix-based,  complex, 
floating  point  arithmetic  employing  various  kinds  of  signal  filtering  and  fast  Fourier  transforms  (FFT) 
operations. 

Many  of  the  above  described  classes  of  parallel  architectures  perfotm  matrix  calculations  extremely  well. 
For  example,  a  128  node  Butterfly  processor  still  has  an  effective  processor  speed  up  of  over  115  nodes 
when  solving  a  400x400  matrix  multiplication  [ 5 | . 

Systolic  arrays  are  also  particularly  known  for  their  efficient  processor  speedup  capability  for  matrices 
and  image  detection  and  manipulation. 

Parallel  network  processing  will  likely  be  used  for  real  time  graphical  portrayal  of  overlayed 
Information  of  terrain,  targets,  weaponry  status,  steering  cues,  vehicle  health  status,  etc. 

ARTIFICIAL  INTELLIGENCE  (AI) 

Codifying  previously  acquired  human  knowledge  and  then  retrieving  It  to  assist  the  aircrew  In 
time-compressed  situations  will  certainly  be  useful  for  future  military  aircraft.  A  large  community  of 
researchera  are  currently  developing  AI  algorithms  for  applications  that  touch  on  virtually  every  area  of 
military  avionics.  For  example,  AI  is  likely  to  play  a  future  role  in  developing  offensive  and  defensive 
tactics,  mission  replanning,  assessing  threat  Intent,  understanding  vehicle 

health  status  and  recommended  reconfiguration  options,  selecting  proper  information  for  presentation  to 
the  aircrew,  selecting  gains  for  flight  control,  controlling  anglnes,  selecting  appropriate 
sensors /parameters  for  fusion,  speech  recognition,  understanding  Images,  etc.  The  resulting  "symbolic" 
processing  requires  simple  operations  such  a  comparison  and  selection,  pattern  matching  and  logical 
operations.  Robust  arithmetic  operations  such  as  floating  point  (needed  by  signal  processing)  are  not 
needed,  leading  to  the  expectation  that  an  array  of  "RISC-llke"  computer  nodes  (with  its  attendant 
simplicity  and  speed  advantages)  will  be  sufficient. 

Unfortunately  however,  the  literature  appears  void  of  examples  of  militarily  significant  real  time 
applications  that  have  bean  demonstrated  to  date,  erven  using  larga  ground-based  computing  networks.  Only 
a  vary  few  A I -oriented  machines  have  entered  the  marketplaca  (e.g..  Connection  Machine);  however,  several 
naw  AI  machines  are  under  development.  [t0]« 
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Reference  [10]  states  that  the  fundamental  AI  operation  is  search,  demanding  Intensive  memory  access  and 
I/O  activities  rather  than  CPU  operation.  Dynamic  resource  allocation  and  load  balancing  are  Important 
design  considerations.  The  large  memory  requirement  compounds  search  time  since  no  "locality  of 
reference”  exists  and  algorithms  are  sometimes  aon-de termini* tic .  [10]  Achieving  reel  time  operation  of 
a  set  of  cooperating  Interactive  AT  modules  is  viewed  as  the  ultimate  challenge  since  ve  must  somehow 
find  a  way  to  schedule  each  module,  forcing  It  to  arrive  at  a  "reasonable"  answer  in  time  to  support 
another  module's  needed  Input. 

Parallel  processing  will  be  mandatory  for  many  real  time  AI  applications  for  future  military  aircraft. 

The  reader  should  however  not  lose  sight  of  the  possibility  that  sowe  Isolated  applications  may  be 
readily  accomplished  by  a  single  high  speed  processor  or  a  small  ensemble  of  processors.  Also,  there  are 
researchers  who  believe  that  improved  knowledge  representation  and  parsed  knowledge  bases  *’111  reduce 
processor  speed  requirements.  Current  estimates  for  the  real  time  Implementation  of  AI  applications 
range  from  a  "few  million"  operations  per  second  for  a  relatively  modest  algorithm  to  a  "few  billion" 
operations  per  second  for  a  robust,  cooperative  AI  system.  Due  to  a  dearth  of  data,  these  estimates 
should  only  be  viewed  as  Indicative  of  the  need  for  much  faster  computing  on  aircraft.  Sench  marks  are 
needed  to  permit  better  speed  sizing  and  they  are  expected  to  be  available  over  the  next  few  years  as 
government,  corporate  and  academic  research  efforts  are  reported.  It  is  the  author's  view  that 
significant  work  remains  in  establishing  which  archltecture(s)  should  be  used  for  efficient  AI  real  time 
processing.  It  may  result  that  the  selected  architecture  will  vary  with  the  type  of  knowledge 
representative. 

INTEGRATED  VEHICLE  CONTROL 


Many  new  capabilities  will  result  If  we  are  able  to  dynamically  Integrate  vehicle  control, 
propulsion/engine  control  and  fire  control  functions.  High  maneuverability  around  ground-based  threats. 
Improved  weapon  firing  opportunities,  missile  evasion  and  Improved  vehicle 

control  during  terrain  following  and  avoidance  should  result.  Maneuvering  flight  during  weapon  delivery 
should  minimize  exposure  and  hence  reduce  lethality. 

The  question  Is  whether  high  speed  parallel  networks  will  be  required  to  affect  proper  Integrated  vehicle 
control  in  that  separate  controls  (e.g.,  engine,  fire  control,  flight  controls)  are  adequately 
accomodated  today  through  uniprocessors  (multiple  computers  are  used  only  for  redundancy). 

The  author  believes  that  three  factors  will  drive  some  Integrated  designs  towards  parallel  network-based 
systems.  These  factors  are:  (1)  the  control  system  will  likely  be  Implemented  as  a  tiered,  hierarchical 
system.  Tiered  levels  Include  (a)  system  control  and  reconfiguration  of  the  Integrated  system,  (b) 
subsystem  functional  control  and  reconfiguration  and  (c)  sensors  and  actuators  with  some  embedded 
processing.  More  complex  processing  algorithms  will  have  to  be  implemented  and  expert  system  algorithms 
will  likely  be  used  as  part  of  the  overall  algorithm  In  detecting  and  isolating  failures  and  selecting 
reconfiguration  strategies.  Even  if  these  AI  algorithms  are  "simple",  high  iteration  rates  (e.g.,  128 
times/ sec)  implies  the  need  for  high  speed  parallel  processing,  it  is  anticipated  that  robust 
matrix-based  state  equations  will  need  to  be  solved  at  high  rates  to  properly  couple  airframe  and 
propulsion  controls.  Also,  fault  tolerant  design  considerations  of  such  an  integrated  system  may  lead  a 
parallel  network  of  many  "simple"  machines  that  are  partitioned  to  accomodate  dedicated  functions  for 
failure  localization  and/or  graceful  degradation.  Extensive  redu:  dancy  of  computing  and  interconnection 
networks  will,  be  required  to  achieve  the  needed  fault  tolerance. 

AIRBORNE  PACKAGING  OPPORTUNITIES 


Use  of  VLSI  circuitry  applied  to  wafer  scale  Integration  and  leading  ultimately  to  three  dimensional, 
stacked  wafer  computers  will  enable  processor  size  reduction  at  least  as  dramatic  as  the  hand-held 
calculator  revolution.  Techniques  for  on-aurface  Interconnection  of  processing  micro-circuit  cells  on 
wafers  are  being  perfected  and  techniques  for  interconnection  stacked  wafers  in  a  "3-P"  array  are  under 
development.  [11] 

The  resulting  "3-D  computer"  will  consist  of  about  90Z  silicon  (as  compared  with  I-I5Z)  with  today's 
military  processors).  Reliability  Is  substantially  enhanced  by  deleting  the  use  of  printed  wiring  boards 
with  its  thousands  of  chip-to-board  solder  connections.  Also,  total  system  speed  of  the  multi-cell  wafer 
Is  dramatically  enhanced  due  to  the  absence  of  high  capacitance  wires  which  inhibit  chip-chip  high  speed 
data  transfer  using  today's  packaging  approach. 

The  designer  can  now  seriously  contemplate  wafer-based  designs  where  input /output ,  processor,  memory, 
control  and  custom  cells  can  be  placed  on  one  wafer,  or  homogeneous  cells  can  be  placed  on  wafers,  with 
data  transfer  between  wafers  accomplished  by  small  metallic  bridges  across  the  array  of  the  wafer  (HI  or 
by  photonic  interconnects.  Simply  statsd,  a  hand-held  (e.g.,  10  cm  x  5  cm)  parallel  processor  capable  of 
execuclng  billions  of  operations  per  second  is  reasonable  by  1995.  For  example.  Reference  [11]  describes 
a  stacked  cellular  array  being  constructed  at  Hughes  Research  Laboratories  in  California,  USA.  This  S1MD 
parallel  processor  was  designed  for  Image  and  signal  processor  applications  and  consists  of  five 
different  wafers.  Very  simple  accumulator  cells  are  used  (32  x  32  cells  on  one  wafer  currently,  with  a 
128  x  128  cells  per  wafer  being  constructed).  About  10  billion  operations  per  second  is  expected  for  a 
15  wafer  (5  different  types)  stack.  [11] 

In  achieving  a  "hand-held  supercomputer",  a  few  basic  caveats  must  be  stated.  First,  there  Is  the 
question  of  achieving  high  yield  of  the  cells  across  the  wafer.  Here,  the  tradeoff  is  basically  one  of 
selecting  the  minimum  feature  size  (and  hence  speed)  of  the  separate  cells.  Heat  removal  problems  may  be 
encountered  If  each  cell  Is  driven  at  high  clock  rates.  Direct  immersion  liquid  cooling  may  be  required 
for  some  designs.  However,  the  side  benefit  of  being  able  to  achieve  "chip-level"  fault  tolerance 
t  becomes  a  reality.  Secondly,  wafer  lnterconection  technology  will  need  to  be  Improved.  One  exciting 

t  possibility  Is  to  use  optical  signal  transfer  between  wafers  (e.g.,  using  gallium  arsenlds  diodes  mounted 

(  on  the  silicon  wafers).  Third,  and  always  very  important,  is  the  algorlthm-to-archltecture  matching 
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problem.  There  are  two  basic  design  choices:  (1)  use  customized,  stacked  vafer  processors  having  unique 
vafers  for  every  high  speed  parallel  network  application  on  the  aircraft.  Although  this  approach 
maximizes  the  processing  speed  and  reduces  wafer  interconnect  complexity,  both  hardware 
design/manufacture/support  and  software  development /support  will  be  quite  expensive  for  such  a  design 
approach,  (2)  use  a  family  of  vafer  modules,  and  replicate  their  common  use  across  various  applications. 
If  this  approach  is  feasible  (it  currently  is  under  Investigation),  the  vafer  Interconnect  structure  will 
be  more  complex  and  processing  speeds,  although  possibly  adequate,  will  not  be  optimum.  However,  using 
CAD/CAM  techniques,  a  limited  set  of  relatively  low  cost  vafers  could  be  designed  and  manufactured  in 
large  quantity,  thereby  permitting  "learning-curve",  high  volume  cost  savings  to  occur.  Further,  the 
concept  of  developing  programmable  topologies  across  the  cells,  thereby  enabling  a  further  dimension  in 
architecture  personalization  to  the  algorithm  Is  possible.  Finally,  a  standard  family  approach  allows 
consideration  of  a  modular  operating  system  that  controls  the  overall  modular  set  of  vafers.  The 
feasibility  of  this  concept  Is  also  under  investigation. 

CONCLUSIONS 


The  potential  applicability  of  parallel  processing  networks  for  future  airborne  applications  is  an 
exciting  concept  which  will  depend  on  the  Integration  of  several  new  technologies.  However,  It  appears 
that  the  queationa  surrounding  these  machines  are  mostly  directed  towards  selecting  which  applications 
will  be  used,  which  network  should  be  used  and  what  technologies  should  be  used  for  the  flyable  design  - 
there  seems  to  be  little  question  about  ultimate  feasibility.  However,  there  will  certainly  be  a  period 
of  "growing  pains"  which  researchers  must  go  through  in  learning  what  architectures  work  for  which 
applications.  However,  complex  and  'ostly  software  Is  the  biggest  concern  since  basic  limits  on 
affordability  could  be  reached  If  sufficient  "front  end"  support  software  la  not  developed. 

Based  on  on-golng  work  in  applications  and  technology,  we  ahould  be  in  a  good  position  to  Judge  the 
general  direction  of  parallel  processing  around  1990.  By  1995-96,  If  proper  funding  is  made  available, 
flyable,  cost  effective  parallel  networks  should  be  a  reality. 
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TABLE  1 


EXAMPLES  OF  AVAILABLE  PARALLEL  PROCESSOR  NETWORKS 


PROCESSOR 

NAME 

MANUFACTURER/ 

DEVELOPER 

TOPOLOGY 

MAX  NO. 

OF  NODES 

BUILT 

|  MAX  MEM. 

PER  NODE 

(Kbytes) 

NODE 

CPU 

WORD 

LENGTH 

SPEED 

(MIPS/NODE) 

COSMIC 

CUBE 

1983 

CAL  TECH, 
PASADENA,  CA 
USA 

HYPERCUBE 

64 

128 

16 

.7 

MARK  II 

1985 

MARK  III 

1986 

JET  PROPULSION 
LAB,  PASADENA, 
CA,  USA 

HYPERCUBE 

HYPERCUBE 

64 

1024 

256 

4K 

32 

32 

1.0 

1.0 

IPSC 

(1985) 

IPSC 

(1987) 

INTEL, 
BEAVERTON , 

OR,  USA 

HYPERCUBE 

HYPERCUBE 

128 

128 

512 

1024 

32 

32 

1.0 

4.0 

CONNECTION 

MACHINE 

(1986) 

THINKING 
MACHINES, 
CAMBRIDGE,  MA 

USA 

HYPERCUBE 

65536 

0.5  j 

1 

.015 

BUTTERFLY 

(1986) 

BOLT,  BERANEK 
&  NEWMAN, 
CAMBRIDGE,  MA 
USA 

BANYON 

SWITCH 

256 

IK 

32 

1.0 

WARP 

CARNEGIE 
MELLON  U. 
PITTSBURGH, PA 
USA 

SYSTOLIC 

ARRAY 

256 

(10  Non) 

16 

32 

10  MFLOPS 

MASSIVELY 

PARALLEL 

PROCESSOR 

GOODYEAR 
AKRON,  OH 

USA 

NEAREST 

NEIGHBOR 

16,384 

IK 

1 

.02  MFLOPS 

COMMON 

SIGNAL 

PROCESSOR 

IBM 

MANASSAS,  VA 
USA 

CIRCUIT  , 

SWITCH 

24  | 

4 

32 

125  MFLOPS 

MtMUKY 
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COMPUTING  system  configurations  FOR  HIGHLY 
INTEGRATED  GUIDANCE  AND  CONTROL  SYSTEMS 


.CEDOCAR 

:  (L'lepact  des  sytemes  informat ipues  avances  sur  la 
flabiilte  de  t'avionlque  mintaire.) 

:  The  impact  of  advanced  computer  systems  on  avionics 
reliability. 

:  BORDEN  A.  G. 

:  Publication  en  serle 
:  Defense  Electronics  (US) 

:  VOL  19;  NO  6;  pp.  S  7-S  21;  12  Ref. ;  6  Fig. ;  DP. 

1987/05 
:  DEELDH 

:  Introduction,  dans  les  systemes  avlontques  Integrant 
toutes  les  fonctlons  d'alde  au  pllote.  des 
techniques  les  plus  avancees  dans  la  science  du 
traltement  de  1 ' Information. 

CEDOCAR 

:  Interconnexions  de  sous-sys temes  :  bus  de  donnees. 

:  Subsystems  interconnection  :  data  buses. 

:  IEEE/A1AA  7th  digital  avionics  systems  conferenc. 

;  Fort  North  (US) 

:  1986/10/13-1986/10/16 

:  Institute  of  Electrical  and  Electronics  Engineers  et 
Al AA  (US) 

:  Memolre  Congres 
;  IEEE  (new  York) 

:  NO  86CH  23598;  pp.  221-254;  nb.  Ref.;  nb.  Fig.,  5 
communications;  DP.  1986 

;  Description  de  divers  bus  de  transmission  de  donnees 
developpes  pour  1 ' Interconnexion  des  divers  systemes 
avlonlques  a  boro  d'un  aeronef. 

.CEDOCAR 

:  (Materiel  de  traltement  de  donnees  pour  spatlonef  : 
la  norme  1750  A  ISA  de  l'US  Air  Force  const Itue  la 
nouvel le  tendance. ) 

;  Data-processlng  hardware  for  spacecraft  :  Air  Force 
standard  1750  A  ISA  Is  the  new  trend. 

:  BYINGTON  L. ;  THEIS  D. 

:  The  Aerosp.  Corp. ,  Los  Angeles.  US:  The  Aerosp. 

Corp. ,  Los  Angeles,  US 
:  Publication  en  serle 
:  Computer  (US) 

:  VOL  19;  NO  11;  pp.  50-59;  12  Ref.;  3  Fig.;  4  Tabl . ; 

Contrat  USAF  No  F04 70 1-83 -0084,  DP.  1986 
:  CPTRB4 
:  0018-9162 

;  L'appllcatlon  de  la  norme  1750  A  de  l'US  Air  Force 
sur  1 ' "architecture  des  ensembles  d' Instruct  ions' 
(ISA)  va  domlner  la  technologle  du  traltement  de 
donnees  aerospat 1  a l es  durant  la  prochalne  decennle 
et  va  permettre  d'embarquer  des  out  11s  de 
developpement  de  loglclels  plus  sophlstlques  a  bora 
des  spatlonefs.  Presentation  de  t'etat  actuel  des 
materlels  et  loglclels  homologues  ou  candidate  pour 
des  applications  spatiates.  La  premiere  famine  (RCA 
1802  series)  de  mlcroprocesseurs  spatlaux  n'est 
desormals  plus  retenue. 

.  CEDOCAR 

:  (PossIDlllte  d'appl Icat ion  aux  avlons  futurs  a 
hautes  performances  des  developpements 
techno loglques  realises  pour  le  F-4  et  le  Tornado. ) 

;  Uebertragbarkeit  technologlscher  welterentwlcklungen 
au  F-4  und  Tornado  auf  aukDnftlge 
Hochlelstungsf lugzeuge. 

:  KUNY  N. 

:  MBS  (DE) 

:  Publication  en  serle 
;  DGLR  Janrbucch  (OE) 

:  VOL  1985/2;  NO  41;  7  p. ;  10  Fig.;  DGLR  85  131;  DP. 
1986 

:  DGLJAN 
:  0070-4083 

;  Avantages  des  transferts  de  technologle  et  examples 
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d' application  au  chasseur  oes  annees  9C  dans  les 
domalnes  :  architecture  des  systemes,  afflchage. 
loglclels.  Integration  des  systemes. 

CEDOCAR 

:  Architecture  de  calculateurs  tolerants  les 
def al 1  lances . 

:  Fault  tolerant  computer  architecture. 

:  NAECON  -  IEEE  1986  National  Aerospace  and 
Electronics  Conference. 

:  Dayton,  US 
:  1986/05/19-1986/05/23 

:  BROCK  L.  D.;  LALA  J.;  THOMPSON  D.  B.;  BORTNER  R.  A.; 
HUNG  J.  Y. 

:  Charles  Stark  draper  lab.  (US);  Charles  Stark  draper 
lab.  (US);  Air  Force  Wright  Aeronautical  labs  (US)‘ 
Air  Force  Wright  Aeronautical  labs  (US);  Air  Force 
Wright  Aeronautical  labs  (US) 

:  Institute  of  Electrical  and  Electronics  Engineers 
(US) 

;  Memolre  Congres 
;  IEEE  (New  York) 

:  VOL  2;  NO  86CH2307-7;  pp .  368-382;  16  Ref.;  6  Fig.; 

2  communications;  DP.  1986 
:  Le  systeme  avance  de  traltement  de  donnees  pour 
vehicules  aerospat laux .  concu  pour  tolerer  les 
defall  lances  et  les  dommages,  se  deter lorer 
progress  1 vement .  etc...  Le  CRMMFCS  :  le  systeme  de 
commande  de  vol  mul t 1 -mlcroprocesseur  a 
reconfiguration  continue. 

CEDOCAR 

:  Fibres  opt  1 dues. 

:  Fiber  optics. 

;  NAECON  -  IEEE  1986  National  Aerospace  and 
Electronics  Conference. 

:  Dayton,  US 
:  1986/05/19-1986/05/23 

:  MCLEAN  J.  R.;  UHL HORN  R.  W.;  FREEBERG  D.  M.  ;  TOROK 
E.  J. ;  STANKOS  W.  C. 

:  Harris  Corp  (US);  Harris  Corp  (US);  Sperry  Corps 
(US);  Sperry  Corps  (US);  Harris  Corps  (US) 

;  Institute  of  Electrical  and  Electronics  Engineers 
(US) 

:  Memolre  Congres 
:  IEEE  (New  York) 

:  VOL  1;  NO  86CH2307-7;  pp .  146-164;  Nb.  Ref.;  Nb. 

Fig.;  3  communications;  DP.  1986 
:  Reseau  de  transmission  par  fibres  optlques  a  boro 
d'un  aeronef  mllltalre  :  caracterlst iques  et 
imperatlfs.  Commutation  optlque  pour  bus  de 
transmission  a  grand  debit.  Opt Imal Isat ion  d'un 
systeme  d' interconnexion  demontable  pour  bus  de 
transmission  de  Oonness  par  fibres  optlques. 

.CEDOCAR 

:  Architectures  d'avlonique  avancee. 

;  Advanced  avionics  architecture. 

:  NAECON  -  IEEE  1985  National  Aerospace  ann 
Electronics  Conference. 

;  Dayton,  US 
:  1986/05/19-1986/05/23 

;  HOEFER  W.  G. ;  ELENGICAL  G. ;  MAKI  S. ;  NORMAN  L.  E.;  0 
REILLY  W.  T. 

;  General  Electrics  (US);  west n 1 ngnouse .  Defense  and 
Electronics  Syst .  (US);  General  Dynamics  (US);  Texas 
Instruments  (US);  West h 1 nghouse  (US) 

.-  Institute  of  Electrical  and  Electronics  Engineers 
(US) 

:  Memolre  Congres 
;  IEEE  (New  York) 

:  VOL  1;  NO  86CH2307-7;  pp.  112-143,  1386-1392;  Nb. 

Ref.;  Nb.  Fig.;  6  communications;  DP.  1986 
;  Architecture  d'un  coprocesseur  d'estlmatlon  de 
parametres.  Evaluation  de  l'etat  de  tonct lonnement 
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des  systemes  d'armes  aeroportes.  Le  calculateur 
correspondent  a  la  rvorme  MIL-STD-1750  A  de  Texas 
Instruments  pour  le  traltement  a  bord  des  avlons 
tactlques  des  donnees  fournles  par  tes  dlfferents 
capteurs.  Une  architecture  redondante  pour  les 
dlfferents  capteurs.  Une  architecture  redondante 
pour  la  tolerance  aux  defall  lances  des  systemes 
d'armes  aeroportes.  Realisation  de  l 'electronique 
des  vehlcules  de  transfert  d'orblte  utlllsant  les 
techniques  de  cout  du  cycle  de  vie.  Des 
architectures  developpees  par  Sanders  multlpllent 
par  un  facteur  de  deux  a  cinq  le  debit  des 
processeurs  MIL-STD-1750  A. 

CEDOCAR 

:  Les  out  11s  des  systemes  experts  et  leurs 
appl icat ions. 

:  Experts  systems  tools  and  applications. 

:  Conference  on  software  tools. 

:  New  York.  US 
:  1985/04/14-1985/04/17 
:  Polytech.  Inst,  of  New  York  (US) 

;  Memolre  Congres 

;  IEEE  Computer  Society  Press  (Washington) 

:  NO  85CH2188-1;  pp.  28-70;  38  Ref.;  19  Fig.;  14 
Phot.:  6  memolres;  DP.  1985 
:  0-818-60628-2 

;  Description  :  du  programme  d'edttlon  OBIE-l 
develoope  pour  des  simulations  interactives 
(notamment  de  tableau  de  bond  d'aeronef  pour 
l 'entralnement  des  equipages);  du  loglcle)  LANST 
concu  pour  la  simulation  de  reseau  locaux;  des 
systemes  experts  BES/SSD  d'alde  a  la  mlse  au  point 
et  a  la  correction  de  loglclels  de  grandes 
dimensions;  de  1'outll  SPACE  II  d'alde  en 
developpement  et  a  la  maintenance  des  loglclels 
( genera lement  en  langage  ADA)  des  forces  armees 
amerlcalnes;  d'un  systeme  expert  d'alde  a  la 
formulation  de  la  politique  monetalre  des 
Etats-Unls;  de  1'outll  de  pelnture  graphlque  DA 
VINCI  avec  base  de  connalssance. 

CEDOCAR 

;  Developpement  d'un  loglclel  de  gestlon  d'interfaces 
systeme. 

;  MOREL  J.  H.;  MOURRE  B. 

:  Ec.  Natl.  Super.  d'Ing.  de  Constr.  Aeronaut .  (FR) 

;  Rapport 
:  ENSICA  85/6 

;  Rapport  de  fin  d'etudes;  71  p. ;  5  Ref.;  NB  Fig.;  NB 
Tabl . ;  DP.  1985 

;  Le  digibus.  Les  coupleurs  d'acces  bus.  Presentation 
du  loglclel.  Programme  d'acqulsltlon  des  parametres. 
Programme  de  test  des  coherences. 

I.  CEDOCAR 

;  Architecture  de  calculateur  numerique  pour  un 
systeme  de  commande  de  vol  de  conception  avancee. 

;  Digital  computer  architecture  as  applied  to  an 
advanced  flight  control  system. 

:  AIAA  Guidance,  Navigation  and  Control  Conference. 

;  Snowmass,  US 
:  1985/06/19-1985/08/21 
:  DIETRICH  A.  R.;  THOMAS  F.  J. 

;  Allied  Bendlx  Aerospace  (US);  Allied  Bendtx 
Aerospace  (US) 

:  AIAA  (US) 

:  Memolre  Congres 

;  The  American  Institute  of  Aeronautics  and 
Astronautics,  New  York 
:  pp.  836-841;  3  Fig.;  1  Tabl.;  DP.  1985 
;  Etude  de  1 'architecture  de  ce  calculateur  et  de  la 
redondance  requlse  pour  assurer  la  survle  de 
1  'aeronef  en  cas  d'une  defat  nance  de  circuit  ou 
d'une  erreur  de  loglclel.  Ce  systeme  de  commande 
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utilise  des  circuits  Integres  a  tres  grande  ecnelle 
(VLSI)  avec  des  bus  de  transmission  numerique  tres 
rap  ides. 

.CEDOCAR 

:  Bus  de  transmission  de  donnees. 

:  Data  bus  concepts  and  practices. 

:  AIAA/IEEE  6tn  digital  avionics  systems  conference. 

:  Baltimore  (US) 

:  1984/12/03-1984/12/06 

:  PENN  0. ;  CHOW  K .  K. ;  SPIETH  J. :  MACNAMERA  B.  J. ; 
DOLECEK  C.  E. 

:  Israel  Aircraft  Ind  (IL);  Lockheed  (US);  US  Air 
Force  (US);  Arlnc  (US);  John  Hopkins  Unlv.  (US) 

;  American  Institute  of  Aeronautics  and  Astronautics 
(US) 

;  Memol re  Congres 
:  AIAA,  New  York 

;  pp.  393-420;  22  Ref . ;  35  Fig.;  1  Tabl . ;  5 
communications;  DP.  1984 

:  Un  bus  standard  pour  les  ca)cu)ateurs  embarques 
MIL-STD- 1750A .  un  bus  de  transmission  de  donnees 
optlque  par  multi  pi  exage  de  longueur  d'onde  pour 
applications  mllltalres.  L' Interface  MIL-STD- 1553  B 
ARINC  561.  Utilisation  de  l ' Intel  1 igence 
artlflclelle  dans  les  reseaux  locaux  CSMA/CD  et  a 
Jetons.  Structures  de  bus  tres  rapldes  pour  le 
multltraltement . 

CEDOCAR 

:  Circuits  Integres  numeriques  avances. 

:  Advanced  digital  integrated  circuits. 

:  AIAA/IEEE  6th  digital  avionics  systems  conference. 

;  Baltimore  (US) 

:  1984/12/03-1984/12/06 

:  FRIEDMAN  S.  N. ;  FORDE  S.  J.;  HILMANTEL  M.  A. 

;  ILC  data  service  corp  (US);  Sanders  associate  (US); 
Sanders  associate  (US) 

:  American  Institute  of  Aeronautics  and  Astronautics 
(US) 

:  Memol re  Congres 
;  AIAA.  New  York 

:  pp.  563-572;  1  Ref.;  9  Fig.;  2  comunlcat Ions ;  DP. 
1984 

;  Performances,  description  et  caracterlst Iques 
electrlques  du  BUS  65112  suprahybrlde.  unite  pour 
terminal  a  distance,  conforme  a  la  norme 
MIL-STD- 1553B .  Circuit  VLSI  pour  calculateur 
embarque. 

.CEDOCAR 

;  Le  calculateur  aeroporte  de  1'avenir. 

:  CONDOM  P . ;  BULLOCH  C . 

:  Publication  en  serle 
;  Interavla  Revue  (CH) 

:  NO  1;  pp.  50-53;  3  Fig.;  DP.  1985/01 
:  INRVBO 
:  0376-9402 

Ensemble  de  deux  articles  relatlfs  d'une  part  aux 
llbertes  et  aux  contralntes  des  commandes  de  voi 
electrlques  et  d'autre  part  au  calculateur  aeroporte 
de  1'avenir  qul  devlendra  de  plus  en  plus  compact, 
raplde  et  Intel l igent . 

.CEDOCAR 

:  Avlonlque  modulalre  standard. 

;  Standardized  modular  avionics. 

;  AIAA/IEEE  6th  digital  avionics  systems  conference. 

;  Baltimore  (US) 

;  1984/12/03-1984/12/06 

:  MULVANEY  S.  p.;  PORADISH  F.  J.;  MCNICHOLS  J.  K.; 

RADCLIFFE  W.  E. ;  KU5EK  J .  L. 

:  General  Dynamics  (US);  Texas  Instruments  (US);  Naval 
Avionics  Center  (US);  ARINC  (US);  General  Dynamics 
(US) 
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:  American  Institute  of  Aeronautics  ana  Astronautics 
(US) 

:  Memo) re  Congres 
:  AIAA .  New  York 

:  pp.  624-652;  5  Ref.;  34  Fig.;  3  Tabl . ;  5 
communications;  DP.  1984 
;  L'avlonlque  de  construction  modulalre.  Un 
calculateur  entlerement  reconf igurable. 

. CEDOCAR 

:  Developpement  d'une  famine  de  calculateurs 
modulalres  pour  le  traltement  de  donnees  de  vol  a 
cout  d' acquisition  minimal. 

:  Development  of  a  modular  air  data  computer  family 
for  minimum  cost  of  ownersmp. 

:  I4tb  congress  of  ICAS. 

;  Toulouse  (FR) 

:  1984/09/10-1984/09/14 
:  COLSON  J.  M. ;  MACKLEY  F.  T. 

;  Marconi  Avionics  Ltd,  Rocnester  (GB);  Marconi 
Avionics  Ltd,  Rocnester  (GB) 

:  Memolre  Congres 
;  ICAS  Congress  (US) 

:  ICAS 

:  VOL  2;  NO  4-9-3;  pp.  1075-1078;  1  Fig.;  4  Phot.;  DP. 
1984 

:  AAUSAK 
:  0-915-92889-2 

:  Les  developpements  de  1 'ut 1 l Isat ion  de  la  conception 
asslstee  par  calculateur  et  de  1 ' integrat ion  a  tres 
grande  echelle  ont  permls  de  concevoir  et  fabriquer 
quatre  varlantes  de  calculateurs  numerlques. 
possedant  un  tronc  commun  electronlque  de  85  pour 
cent  et  pouvant  et re  adaptees  a  30  types  distlncts 
d'aeronefs.  Etude  des  parametres  economlques  de  ces 
calculateurs.  Description  du  hardware  et  des  essals 
en  vol . 

. CEDOCAR 

:  (Architecture  des  calculateurs  destines  a 
1 'avlonlque.  ) 

.-  Avionics  computer  architecture. 

NICHILS  0. 

:  Publication  en  serle 
:  International  Defense  Review  (CH) 

:  VOL  17/9;  pp.  50-53;  8  Fig.;  Special  Electronics  No 
2/84;  DP.  1984 
:  IORVAL 
:  0020-6512 

;  Dlverses  categories  d'archltectures  de  calculateurs. 
Les  calculateurs  sequent lels.  Exemples  de 
multlprocesseurs  pour  systemes  avlonlques.  Les 
premiers  processeurs  paralleles  aeroportes. 

.CEDOCAR 

:  L'avlonlque  du  F/a-18. 

;  Advanced  F/A-18  avionics. 

;  Advanced  concepts  for  avionics/weapon  system  design, 
development  and  integration. 

;  Ottawa  (Canada) 

:  1983/04/18-1983/04/22 
:  DRUMMOND  R.  C.;  LOOPER  J.  L. 

■  McDonnei  Douglas;  McDonnel  Douglas 
;  Advisory  group  for  aerospace  reserch  and 
development 
:  Memolre  Congres 

;  Agard  conference  proceedings  (FR) 

;  Agard  (Neul 1 ly/Selne) 

:  NO  CP  343;  pp.  15.1-15.12;  12  Fig.;  DP.  1983 
;  AGCPAV 
;  0549-7191 

;  Description  du  systeme  avtonlque/systeme  d'arme. 
Circuits  Integres  a  grande  echelle  et 
mlcroprocesseurs  d'apres  la  norme  MIL  STD  1553A. 
Missile  AMRAAM.  Systeme  d' Information  JTIDS. 
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-18-  162950  C.CEDOCAR 

tltre  fr.  :  Conference  sur  les  calculateurs  dans  le  domaine 

aerospat ial . 

Titre  conf.  :  Computers  in  Aerospace  Conference. 

LIEU  DE  CONF.  :  Hartford,  CT ,  Etats-Unis 

DATE  CONF.  :  1983/ 10/24- 1983/ 10/26 

Auteur  coll.  :  Amer .  Inst,  of  Aeron.  and  Astronautics 

type  de  doc.  :  Congres 

editeur  :  Amer.  Inst,  of  Aeron.  and  Astronautics 

Source  :  NO  4;  502  p. ;  DP.  1983 

resume  :  Recueil  de  68  memoires  signales  en  detail  dans  les 

International  Aerospace  Abstracts  volume  24.  No  i  du 
01/01/84. 

-19-  152566  C.CEDOCAR 

titre  fr.  :  (Sur  les  systemes  numeriques). 

tltre  ang.  :  Digital  system  topics 

Auteurs  :  CAMPBELL  H.  W. 

Auteur  coll.  :  Institute  of  Electrical  and  Electronics  Engineers 

type  de  doc.  :  Publication  en  Serie 

Titre  pub 11 .  :  IEEE  Conference  Publication  (US) 

Source  :  VOL.  1.  NO  83CH1868-9  (1983),  PP.  670-694;  17  ref.  , 

17  fig.,  4  tapl.  NAECON  83,  Dayton.  OH.  17-19/05/83 
CODEN  :  ICH024 

resume  :  Ouatre  articles  traitent:  d'un  programme  totalement 

Interact  if  pour  1 'evaluation  de  la  fiabilite  ae 
systemes  numeriques  tolerant  les  erreurs;  de 
techniques  d'anaiyse  de  fiabilite  et  de  soutien 
logistique  pour  avionique  tolerant  les  erreurs:  de 
simulations  appliquees  a  la  conception  d'un  systeme 
multiplex  integre  pour  1 'avionique  pour  neiicoptere 
Agusta  a  129;  d'une  architecture  pour  systemes 
d' informat ique  repart ie  fonctionnant  en  temps  reel. 

-20-  144755  C.CEDOCAR 

tftre  fr.  :  (L'armee  de  l 'air  aroericaine  etudie  un  nouveau 

concept  de  caiculateur ) . 

tltre  ang.  :  USAF  studies  new  computer  concept 

Auteurs  :  ELSON  B.  M. 

type  de  doc.  ;  Publication  en  Serie 

Titre  pubii.  :  Aviation  Week  and  Space  Technology  (US) 

Source  ;  VOL.  118.  NO  19  (9/5/83).  PP.  69-71;  2  fig. 

CODEN  :  AWSTAV 

resume  ;  Le  laboratoire  de  dynamique  de  vol  de  1'US  Air  Force 

evaiue  une  architecture  de  caiculateur 
mul t imlcroprocesseur  pour  commande  de  vol 
susceptible  de  redulre  largement  ie  cout  des 
caicuiateurs  tolerant  les  defai nances  et  de 
multiplier  plusieurs  fois  le  temps  disponiple  entre 
les  operations  de  maintenance  Dlanifiee  de  ces 
systemes.  Des  microprocesseurs  autonomes  sont 
re 1  lees  par  un  ensemble  commun  de  bus  de  donnees, 
ils  comprennent  des  unites  actives  et  des  unites  en 
reserve  (60  et  40  environ  respect ivement ) .  chaque 
processeur  etant  capable  d'effectuer  n'importe 
quelle  tache  a  n'imDorte  quel  moment. 

-21-  144126  C.CEDOCAR 

tltre  fr.  :  (Microcatculateur  operatlonnel  tolerant  les 

defail  lances  pour  une  fiabilite  tres  eievee). 
titre  ang.  :  Operational  fault-tolerant  microcomputer  for  very 

high  re  1 iabl 1 ity 

Auteurs  ;  MASHKURI  YAACOB;  HARTLEY  M.  G. ;  DEPLEDGE  P.  G. 

Affiliation  :  (1)  Univ.  of  Malaya.  Malalsie,  (2,3)  Univ.  of 
Manchester  (GB) 

type  de  doc.  :  Publication  en  Serie 

Titre  pubii.  :  IEE  Proceed  1 ngs-E-Computers  and  Digital  Technique 
(US) 

Source  :  VOL.  130.  NO  3  (5/83).  PP .  90-94;  17  ref.  .  4  fig., 

i  tabl . 

CODEN  ;  IJCTDJ 

Issn  :  0143-7062 

resume  :  Description  d'un  mlcrocalculateur  a  triple 

redondance  modulaire  concu  pour  fonctionner  pendant 
3  heures  a  bord  d'un  aeronef ,  avec  une  probabilite 
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-22-  139562 
tltre  fr 

tttre  ang. 
Auteurs 
Affiliation 
type  de  doc. 
Tltre  publ 1 . 
Source 


COOEN 

Issn 

resume 


-23-  131699 
tltre  fr. 

tltre  ang. 

Auteurs 

Affiliation 


type  de  doc. 
Tltre  publ 1 . 
Source 


COOEN 

resume 


-24-  131697 
tltre  fr. 

tltre  ang. 

Auteurs 

Affiliation 

type  de  doc. 
Tltre  publ 1 . 
Source 


COOEN 

resume 


-25-  130669 
tltre  fr. 
tltre  ang. 
Auteurs 
Aff 1 1 latton 


type  de  doc. 
Tltre  publ l . 
Source 
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de  panne  Inferleure  a  1  sur  10  exp.  B.  11  utilise  un 
reseau  de  mlcroprocesseurs  Motorola  M  6800. 

•CEDOCAR 

:  (Systemes  de  gestlon  de  vol  et  systemes  de 
communication). 

:  Flight  management  systems  and  data  links 
:  HENDRICKSON  T.  W. 

:  (1)  BOEING  COMPANY 
:  Publication  en  Serle 
:  The  aeronautical  Journal  (GB) 

:  VOL.  87,  NO  862  (02/83).  PP .  52-67;  6  ref .  ,  20 
fig..  5  tab).  No  1054.  Conference  -Today  and  tomorew 
mini  and  micro  computers  1r.  airline  operations. 

10/82 
;  AENJAK 
;  0001-9240 

:  Presentation  de  ('architecture  et  des  interfaces  du 
systeme  digital  de  gestlon  de  vol  mis  au  point  par 
Boeing  pour  )e  757  et  767. 

•CEDOCAR 

:  (Application  de  1 ' Informat Ique  dlstrlbuee  aux 
systemes  avlonlques). 

:  Application  of  distributed  system  designs  to  avionic 
systems 

:  MOSES  K.;  NELSON  H. ;  WILCOCK  G.  W.  ;  LANCASTER  P. 

:  (1)  Bendlx  Corp  (US).  (2)  Navi  Weapons  Center  (US). 
(3)  Royal  Aircraft  Establ Isnment  (GB).  (4)  British 
Aerospace  (GB) 

:  Publication  en  Serte 
:  AGARD  Conference  Proceedings 

:  VOL.  CP-303  (1981).  PP.  32.1-57.3;  nDr.  ref.  .  nbr . 
fig.,  nbr.  tabl .  Tactical  Airborne  Distributed 
Computing  and  Networks.  Roros  22-25/6/81 
:  AGCPAV 

:  Sept  communications.  Comma nde  integree  des  systemes 
mecanlques  pour  le  futur  avion  de  combat. 
Architecture  du  systeme  d'armes  du  Mirage  2000. 
Calculateurs  et  unites  de  soutlen  du  systeme  d'armes 
des  avlons  F/a-18  et  f/a-iba.  Conception  d'un  reseau 
Informatlque  ultra-flable  pour  avlonique. 

.CEDOCAR 

:  (Tolerance  aux  defalllances  et  flablllte  dans  la 
conception). 

:  Fault  tolerance  and  reliability  in  designs 
:  STERN  A.  D.;  MC GOUGH  J.  G. ;  SWERN  F.;  BAVUSO  S.  J. 

:  (1)  Boeing  Co.  (US).  (2,3)  Bendlx  Corp.  (US).  (4) 
Nasa  (US) 

:  Publication  en  Serle 
;  AGARD  Conference  Proceedings 

:  VOL.  CP-303  (1981),  PP .  20.1-S5.2;  nbr.  ref.  .  nbr. 
fig.,  nbr.  tabl.  Tactical  Airborne  Distributed 
Computing  and  Networks  Roros  22-25/6/81 
:  AGCPAV 

:  Cinq  communications.  Mtsthodologle  pour  evaluer  le 
risque  de  panne  d'un  mlnlprocesseur  avlonique 
numerlque.  Specification  hlerarchlsee  d'un  systeme 
de  commande  de  vol  tolerant  des  defalllances.  Reseau 
d'echange  reconf igurable  pour  controle  de  processus 
reparti . 

. CEDOCAR 

:  (Methodes  de  conception  d'un  systeme  dlstrlbue). 

:  Distributed  system  design  approaches 
:  CALLAWAY  A.  A.;  PRIESTER  R.  W. ;  BROMLEY  K.;  CLARY  J. 
.-  (1)  Royal  Aircraft  Establishment  (GB),  (2)  Research 
Triangle  Inst.  (US).  (3,4)  Naval  Ocean  Systems 
Center  (US) 

:  Publication  en  Serle 
:  AGARD  Coference  Proceedings 

:  VOL.  CP-303  (1981).  PP.  11.1-53.3;  nbr.  ref.  .  nbr. 
fig.,  nbr.  tabl.  Tactical  Airborne  Distributed 
Computing  and  Networks,  Rorors  22-25/6/81) 


CODEN 

Isbn 

resume 


-26-  129190 
tltre  fr. 
Auteurs 
type  oe  ooc. 
edlteur 
Source 


resume 


-27-  125245 
tltre  fr . 


tltre  ang . 

Auteurs 
Affiliation 
type  de  doc. 
Tltre  pud  1 . 
Source 
CODEN 
Issn 
resume 


-28-  107681 
tltre  fr. 

tltre  ang. 
Auteurs 
type  de  doc. 
Tltre  publ 1 . 
Source 

COOEN 

resume 


-29-  102277 
tltre  fr. 


Auteurs 

Auteur  col  1 . 
type  de  doc. 
Tltre  publ 1 . 
no  brevet 
Source 

CODEN 

resume 
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:  AGCPAV 
:  92-835-0302-3 

:  Ouatre  communications.  Presentation  d'une  tecnnlQue 
de  gestion  de  base  de  donnees  destlnee  a  verifier 
1 'architecture  d'un  systems  d' Informat Igue  repartle. 
Net nodes  de  traltement  de  signal  a  1'alde  de  reseaux 
systollques.  Commands  informatlsee  dlstrlbuee  en 
temps  reel  pour  les  systemes  avlonlque  des  ae-onefs 
embarques  sur  parte  avions. 

C.CEDOCAR 

:  Les  calculateurs  de  gestion  de  vol . 

:  GROSSIN  M.  J. 

:  Ouvrage 

:  Instltut  Francats  de  Navigation 
:  VOL.  1,  NO  FP  4  (1982),  17  P.;  10  fig.  Congres 
International  des  Instltuts  de  Navigation,  Paris, 
21-24/09/82 

:  Equlpement  des  avions  clvlls  de  la  nouvelle 
generation  avec  un  systeme  FMS  unique  pour  la 
navigation  norlzontale  et  vert  tea le:  architecture  du 
FMS  et  opt Imal isat Ion  du  vol. 

C.CEDOCAR 

;  (Specification  forme! le  et  verification  mecanlque  du 
calculateur  SIFT:  un  systeme  de  commande  de  vol 
tolerant  les  defal 1  lances) . 

:  Formal  specification  and  mechanical  verification  of 
SIFT:  a  fault-tolerant  flight  control  system 
.  MELLIAR  SMITH  P.  M. ;  SCHWARTZ  R.  L. 

:  (1,2)  SRI  Intern. ,  US 
:  Publication  en  Serle 
:  IEEE  Transactions  on  Computers  (US) 

:  VOL.  31.  NO  7  (07/82),  PP.  616-630;  1 1  ref .  .9  fig. 

:  ITC0B4 
:  0018-9340 

:  Presentation  des  methodes  d'essai  employees  pour 
demontrer  quo  ce  calculateur  repondait  aux 
specifications  de  tolerance  de  defal llance  propres 
aux  systemes  de  commande  de  vol,  tel les  qu'eiles  ont 
ete  flxees  par  la  FAA  et  la  NASA. 

C.CEDOCAR 

:  (Le  LHX :  une  conception  de  systeme  avlonlque 
avance) . 

:  LHX:  an  advanced  avionics  system  design 
:  D  AVINO  D.  S. ;  SPIEGEL  S.  S. 

:  Publication  en  Serle 

:  AIAA/IEEE  Digital  Avionics  Conference  (US) 

:  VOL.  4,  NO  2249  (11/81),  PP.  156-162;  5  fig.  (St 
Louis  (Mo.),  17-19/11/81) 

:  AAPRAQ 

:  Description  de  l 'architecture  de  cet  equlpement 
avlonlque  destine  aux  systemes  d'armes  avances  des 
annees  90  et  en  partlculler  aux  hel Icopteres. 

C.CEDOCAR 

:  Software  :  design  and  control  of  software  dominated 
systems;  (Le  loglclel  ;  conception  et  commande  des 
systemes  ou  le  loglclel  Joue  un  role  dominant). 

:  CACERES  R.  G.;  WARD  J.  W. ;  BERLACK  H.  R. ;  TOULOUSE 
P. ;  SUTTON  R.  W. 

:  Radio  Technical  Commission  for  Aeronautics 
;  Publication  en  Serle 

;  Proceedings  of  the  1981  RTCA  Assembly  (US) 

SBN  0145-9569 

■  NO  1981  (1981).  PP.  123-213;  nombr .  fig.  (3e 
Session) 

:  RTCABR 

:  Cinq  memolres  ;  conception  du  loglclel  pour  la 
systeme  de  guldage  numerlque  du  DC-9  Super  80; 
application  des  normes  de  conception  du  loglclel  a 
1 'equlpement  des  avions  commerclaux;  controie  de  la 
configuration  du  materiel  et  du  loglclel;  le 
loglclel  dans  1 'homologation  des  nouveaux  avions 
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clvlls  oe  transport  europeens;  le  loglclel  dans 
l ' nose  logs t  ton  das  sys tanas  at  aqulpemants  da  Horn. 

-30-  74757  C.CEDOCAR 

t'tre  ang.  :  Software  standardization  and  MIL-STD-1750. 

Autaurs  :  HERRELK.0  D.  A.;  DENTON  0. 

type  da  doc.  :  Publication  an  Serle 

Tltre  pupil.  :  Institute  of  Electrical  and  Electronics  Engineers. 

New  York,  National  Aerospace  and  electronics 
conference 

Source  ;  VOL.  2.  NO  I960  (1990).  PP.  880-91:  25  ref.  (Dayton 

(Ohio),  20-22/5/80,  AB1-30226) 

CODEN  :  10024 

-31-  74736  C.CEDOCAR 

tltre  ang.  :  Fault  tolerance  applications  to  future  military 

system  avionics. 

Auteurs  :  HARRIS  R.  L. :  JONES  E.  E. 

type  da  doc.  :  Publication  en  Serle 

Tltre  publl.  :  Institute  of  Electrical  and  Electronics  Engineers. 

New  York,  National  Aerospace  and  electronics 
conference 

source  :  VOL.  1,  NO  1980  (1980).  PP.  412-419;  20  ref.  (Dayton 

(Ohio),  20-22/5/80.  A81-30226) 

COOEN  :  ICH024 
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-1-  618419  C.NTIS 

Tltre  anglais  :  New  Technology  Impacts  on  Future  Avionics 
Architectures. 

Ref.  Conference  :  This  article  Is  from  'Advanced  Computer  Aids  in  the 
Planning  and  Execution  of  Air  Warfare  and  Ground 
Strike  Operations:  Conference  Proceedings,  Meeting 
of  the  Avionics  Panels  of  AGARD  (51st)  Held  in 
Kongsoerg,  Norway  on  12-16  May  1986.'  AD-A182  096. 
plO-i-io-7. 

Auteurs  :  MEJZAK  R.  S. 

Organlsme  auteur:  Naval  Air  Development  Center,  Warminster,  PA. 

Type  Document  :  Conference 

Source  :  NP.  7;  NT IS  Prices:  PC  A02/MF  A01;  DP.  C1986 

Resume  ;  This  paper  provides  an  interpretat ton  of  avionics 

architecture  with  respect  to  system  components, 
organization,  and  design  factors.  Initially,  general 
avionics  architecture  characterlst ics  are  addressed 
followed  Dy  discussions  on  emerging  new  technologies 
and  their  impact  and  advanced  systems.  Information 
handling  requirements  are  projected  for  future 
tactical  aircraft.  In  addition,  advanced  avionics 
architecture  design  consideration  and  technical 
issues  are  addressed  relative  to  achieving  improved 
performance,  reliability,  survivability,  flexibility 
and  low  life  cycle  cost.  (Author). 

-2-  616504  C.NTIS 

Tltre  anglais  :  Impact  of  Future  Avionics  Technology  on  the  Conduct 
of  Air  Warfare. 

Auteurs  :  OASARO  J.  A. 

Organlsme  auteur:  Army  Avionics  Research  and  Development  Activity, 

Fort  Monmouth,  NJ.*Natlona1  Aeronautics  and  Space 
Administration,  Washington,  DC. 

Type  Document  :  Report 

Source  :  In  AGARO  Improvement  of  Combat  Performance  for 

Existing  and  Future  Aircraft,  9p. ;  NP.  9;  NTIS 
Prices:  (Order  as  N87-22663  PC  A07/MF  A01);  DP.  Dec 
86 

Resume  :  A  synopsis  Is  given  of  the  conclusions  reached  by 

the  Systems  Subpanel  of  the  NATO  AGARD  workshop  on 
the  potential  Impact  of  development  in  electronic 
technology  on  the  future  conduct  of  air  warfare. 
Avionic  system  integration  technology,  system 
architecture,  data  processing,  data  communication 
paths,  computer  programs,  fault  detection  and 
Isolation,  and  system  design  methodology  are  among 
the  topics  discussed. 

-3-  602192  C.NTIS 

Tltre  anglais  :  Potential  Impact  of  Developments  in  Electronic 
Technology  on  the  Future  Conduct  of  Air  Warfare, 
volume  3. 

Organlsme  auteur:  Advisory  Group  for  Aerospace  Research  and 
Development,  Neul 1 ly-sur-Selne  (France). 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  AGARD-AR-232-V0L-3 

Source  :  See  also  volume  2,  AD-C040  122.  Presented  at  AGARD 

Avionics  Panel  Workshop,  The  Hague,  Netherlands, 
21-25  Oct  85.;  NP.  118;  NTIS  Prices:  PC  A06/MF  A01 ; 
DP.  Dec  86 

Resume  :  Today  the  Warsaw  Pact  nations  enjoy  a  large 

Quantitative  advantage  In  equipment  that  is  offset 
by  superior  technology  In  our  weapons  systems. 
Nevertheless,  most  agree  that  continued  exploitation 
of  emerging  technologies  Is  needed  by  NATO  to 
maintain  a  qualitative  lead,  and  that  continued 
progress  in  microelectronics  and  information 
processing  offers  opportunities  for  NATO  to  maintain 
its  technical  superiority.  The  development  of 
electronic  technology  continues  unabated.  Advances 
in  microelectronics  are  resulting  in  circuit 
densities  many  orders  of  magnitude  greater  than  in 
current  usage,  making  possible  higher  speed 
circuitry  and  greater  storage  capacity.  At  the  same 
time,  evolving  RG  techniques  are  leading  to 
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-A-  595437  C.NTIS 
Titre  anglais 
Ref.  Conference 

Auteurs 

Organisms  auteur: 

Type  Document 
RPT.CTR.GRT 

Source  : 

Resume 


-5-  585327  C.NTIS 
Titre  anglais 


Auteurs 

Organisms  auteur: 
Type  Document 
Source 

Resume 


-6-  566524  C.NTIS 
Titre  anglais 

Auteurs 

Organisms  auteur: 


monolitnic  microwave  integrated  circuits  and 
mlcrostrlp  antennas  wltn  corresponding  reductions  in 
size  and  waignt.  In  addition,  rapid  advances  are 
taking  place  in  computer  architecture  and  software 
that  will  provide  improved  Information  processing 
and  control.  This,  coupled  with  progress  in 
artificial  intelligence  and  man-machine  interface, 
offers  promise  of  greatly  improved  battle  management 
in  the  cockpit.  The  scale  of  changes  is  such  that 
the  nature  of  air  warfare  should  be  significantly 
affected  over  the  next  twenty  years.  (NATO 
furnished) . 


Aircraft  Integrated  Data  System  (AIDS). 

13.  symposium  on  Aircraft  Integrated  Data  Systems 
(AIDS- 13) .  Hamburg  (Germany,  F.R.).  17-19  Sep  1985. 
KALBE  H. 

Messerschmltt-Boelkow-Blohm  G.m.b.H.,  Munich 
(Germany,  F.R.).  Information  und  Dokumentat ion. 
Conference 

RPT  MBB-UT— 67/85-0e 
NP.  13:  NTIS  Prices:  PC  E07;  DP.  1985 
The  experiences  with  the  Aircraft  Integrated  Oata 
System  (AIDS)  over  several  years  In  the  A-310  are 
reported.  The  situation  referring  to  the  customer 
requirements,  the  systems  goals  and  the  integration 
problems  are  discussed.  The  repercussions  of  these 
aspects  on  the  systems  architecture  and  a  solution 
which  covers  these  problems  are  presented.  (RHM). 
(Copyright  (c)  1986  by  Fiz.  citation  no. 

86:080824. ). 


Synerglstlcally  Integrated  Reliability  Architecture: 
a  Reliability  Analysis  of  an  uitra-Rei labie  Fault 
Tolerant  Computer  Design. 

NELSON  D.  J. 

Naval  Postgraduate  School,  Monterey.  CA. 

Thesis 

Master's  thesis;  NP.  137;  NTIS  Prices:  PC  A07/MF 
A01:  DP.  26  Sep  86 

This  thesis  develops  a  Semi-Markov  reliability  model 
for  the  Synerglstlcally  Integrated  Reliability  (SIR) 
computer  architecture.  The  SIR  architecture  is  an 
advanced  hybrid  redundancy  scheme  that  combines 
several  current  reliability  techniques  to  achieve 
hardware  and  software  reliability.  These  methods 
include  hybrid  redundancy,  N-version  programming  and 
source  congruent  data  Interchange.  The  architecture 
is  designed  to  support  active  control  systems  in  the 
aircraft  Industry  as  well  as  the  bus  controller 
requirements  for  the  Dispersed  Sensor  Processor  Mesh 
(DSPM)  system  for  ultra-reliable  computer 
communications.  The  paper  also  develops  high  level 
algorithms  for  fault  detection,  location,  and 
configuration  management  within  the  SIR  system.  The 
reliability  model  integrates  the  hardware  design, 
the  hybrid  redundancy  philosophy,  and  the  operating 
constraints  of  an  active  control  system  into  a 
single  reliability  model.  Specific  models  are 
developed  for  the  3.  4,  and  5  processor  cases  of  the 
SIR  architecture  and  plots  of  the  system  reliability 
vs  mission  time  are  generated  using  the  SURE 
Reliability  Analysis  Program. 


Investigation  of  an  Advanced  Fault  Tolerant 
Integrated  Avionics  System. 

DUNN  W.  R. J  COTTRELL  D. ;  FLANDERS  J.;  JAVORNIK  A.; 
RUSOVICK  M. 

University  of  Southern  Colorado,  Pueblo.  School  of 
Applied  Science  and  Engineering  Technology. "National 
Aeronautics  and  Space  Admlnlstrat ion,  Washington, 
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Report 

RPT  NAS  1.26: 176980;  CTR  NCC2-2TT 
Final  technical  rept.  Nov  B3~Mar  86.:  NP.  76:  NTIS 
Prices:  PC  A05/MF  AOI;  Monitor  NASA-CR- 176980,  DP. 
Mar  86 

Presented  Is  an  advanced,  fault-tolerant 
•uniprocessor  avionics  architecture  as  could  be 
aaployed  in  an  advanced  rotorcraft  such  as  lhx.  The 
processor  structure  Is  designed  to  interface  with 
existing  digital  avionics  system  and  concepts 
including  the  Army  Digital  Avionics  System  (ADAS) 
cockpit /display  system,  navald  and  communications 
suites,  integrated  sensing  suite,  and  tne  Advanced 
Digital  Optical  Control  System  (ADOCS).  The  report 
defines  mission,  maintenance  and  safaty-of-f l ignt 
reliability  goals  as  night  be  expected  for  an 
operational  LHX  aircraft.  Based  on  use  of  a  modular, 
compact  (16-bit)  microprocessor  card  family,  results 
of  a  preliminary  study  examining  simplex,  dual  and 
standby-sparing  architectures  Is  presented.  Given 
the  stated  constraints,  It  Is  shown  that  the  dual 
architecture  is  best  suited  to  meet  reliability 
goals  xlth  minimum  hardware  and  software  overhead. 
The  report  presents  hardware  and  software  design 
considerations  for  realizing  the  architecture 
including  redundancy  management  requirements  and 
techniques  as  «ell  as  verification  and  validation 
needs  and  methods. 

-7-  532889  C.NTIS 

Titre  anglais  :  Reliability  Aspects  of  Software  for  Digital 
Avionics. 

Auteurs  :  DEKKER  G.  J. 

Organlsme  auteur:  National  Aerospace  Lab..  Amsterdam 

(Net her lands). 'National  Aeronautics  and  Space 
Administration,  Washington,  DC. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  NLR-TR-82126'U;  RPT  B8568394;  CTR  RB-RLB- 1982-1 - 

3.3 

Source  :  Revised.:  NP.  95;  NTIS  Prices:  PC  A05/MF  AOI :  DP. 

1985 

Resume  :  Methods  to  develop  reliable  software  based  avionics 

systems,  especially  for  safety  critical  functions, 
are  reviewed.  The  differences  between  analog  and 
digital  systems,  and  the  policy  of  the  faa  to 
certify  software  based  systems  are  presented. 

Methods  to  minimize  the  number  of  errors  during 
software  development,  methods  to  remove  as  many 
errors  as  possible  via  testing,  and  methods  to 
minimize  the  effect  of  remaining  errors  during 
operational  flights  are  outlined.  A  safety  analysis 
regarding  common-mode  failures  is  given  Reliability 
related  techniques  used  by  avionics  manufacturers 
are  discussed. 

-8-  498229  C.NTIS 

Titre  anglais  :  Development  and  Evaluation  of  a  Fault-Tolerant 

Multiprocessor  (FTMP)  Computer,  volume  3.  ftmp  Test 
and  Evaluation. 

Auteurs  :  LALA  J.  H.;  SMITH  T.  B. 

Organlsme  auteur:  Charles  Stark  Draper  Lab.,  Inc.,  Cambridge, 

MA. 'National  Aeronautics  and  Space  Administration, 
Washington,  DC. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  NAS  1.26:166073:  RPT  CSDL-R-1602-V-3;  CTR  NAS1- 
15336 

Source  :  Final  rept.;  NP.  1 15;  NTIS  Prices:  PC  A06/MF  AOI; 

Monitor  NASA-CR- 166073;  DP.  May  83 

Resume  :  The  experimental  test  and  evaluation  of  the 

Fault-Tolerant  Multiprocessor  (FTMP)  is  described. 
Major  objectives  of  this  exercise  Include  expanding 
validation  envelope,  building  confidence  in  the 
system,  revealing  any  weaknesses  in  the 
architectural  concepts  and  in  their  execution  in 
hardware  and  software,  and  In  general,  stressing  the 


Type  Document 

RPT.CTR.GRT 

Source 


Resume 
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hardware  and  software.  To  tM*  ana,  pin-lava)  faults 
tiara  injected  Into  ona  LRU  of  th*  FTMP  ana  th*  FTMP 
tm  ports*  *as  aaasurad  In  tarns  of  fault  Oat  act  Ion, 
Isolation,  ana  racovary  times.  A  total  of  21,055 
stuck-at-O,  stuck-at-l  and  invert-signal  faults  *er* 
injected  In  tna  CPU,  aaaory,  bus  Intarfaca  circuits, 
■us  Guardian  units.  and  votars  and  arror  latchas.  Of 
thasa,  17,418  aara  Oat act ad  At  laast  BO  parcant  of 
undatactad  faults  ara  estimated  to  ba  on  unusad 
pins.  Tna  mul  1 1  processor  idantlflad  all  da  tact  act 
faults  corractly  and  racovarad  succassfully  in  aach 
casa.  Total  racovary  tlaa  for  all  faults  avaragad  a 
itttla  ovar  on*  sacond.  mis  can  b*  reducad  to  naif 
a  sacond  by  including  appropriate  salf-tasts. 

-9-  494228  C.NTIS 

Tit  re  anglais  :  Oavalopaant  and  Evaluation  of  a  Fault-Tolarant 
Multiprocessor  (FTMP)  Computer.  Volume  2.  FTMP 
SoftMare. 

Auteurs  :  LALA  J.  H.  ;  SMITH  T.  B. 

Organism*  auteur:  Charles  Stark  Draper  Lab.,  Inc.,  Cambridge, 

MA. ‘National  Aeronautics  and  Space  Administration, 
Washington,  DC. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  NAS  1.25:188072;  RPT  CSDL-R-1601-V-2;  CTR  NAS1- 
15336 

Source  :  Final  rapt . ;  NP.  234;  NTIS  Prices:  PC  All/MF  A01; 

Monitor  NASA-CR- 186072;  DP.  May  83 

Resume  :  The  software  developed  for  the  Fault-Tolarant 

Multiprocessor  (FTMP)  Is  described.  The  FTMP 
executive  Is  a  t tmer- Interrupt  driven  dispatcher 
that  schedules  Iterative  tasks  which  run  at  3.125, 
12.5,  and  25  Hi.  Major  tasks  which  run  under  the 
executive  include  system  configuration  control, 
flight  control,  and  display.  Th*  flight  control  task 
includes  autopilot  and  autoland  functions  for  a  Jet 
transport  aircraft.  System  Displays  include  status 
displays  of  all  hardware  elements  (processors, 
memories.  I/O  ports,  buses),  failure  log  displays 
showing  transient  and  hard  faults,  and  an  autopilot 
display,  ah  software  is  in  a  higher  order  language 
(AEO,  an  ALGOL  derivative).  The  executive  is  a  fully 
distributed  general  purpose  executive  which 
automatically  balances  the  load  among  available 
processor  triads.  Provisions  for  graceful 
performance  degradation  under  processing  overload 
are  an  Integral  part  of  th*  scheduling  algorithms. 

-10-  496026  C.NTIS 

Tltr*  anglais  :  Navy  Should  Join  th*  Air  Force  and  Army  Program  to 
Develop  an  Advanced  Integrated  Avionics  System. 

Organism*  auteur:  General  Accounting  Office,  Washington,  DC.  National 
Security  and  International  Affairs  Olv. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  GAO/NSI AD-85-94;  RPT  8-215379 

source  :  NP.  17;  NTIS  Prices;  PC  A02/V  A01 ;  DP.  17  Jun  85 

Resume  :  Modern  technology  should  soon  enable  separate 

avionics  systems  in  an  aircraft  to  be  consolidated 
into  a  single  package  to  conserve  space,  save 
weight,  and  reduce  costs.  Th*  report  points  out  the 
potential  benefits  of  avionics  consolidation  and 
recommends  th*  Navy  Join  In  a  demonstration  program 
now  being  conducted  by  the  Air  Force  and  Army  to 
exploit  such  benefits. 

-11-  487455  C.NTIS 

Tltr*  anglais  :  Rotorcraft  Digital  Advanced  Avionics  System  (RODAAS) 
Functional  Description. 

Auteurs  :  PETERSON  E.  M. ;  BAILEY  J. ;  MCMANUS  T.  J . 

Organisms  auteur:  Honeywell,  Inc.,  St.  Louis  Park,  MN.  Military 
Avionics  Dlv. •National  Aeronautics  and  Space 
Administration,  Washington,  DC. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  NAS  1.26:166611;  CTR  NAS2-11695 

Source  :  NP.  188;  NTIS  Prices;  PC  A09/MF  AOi ;  Monitor 
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NASA-CR-166611;  DP.  Jan  85 

Rasuaa  :  A  functional  design  of  a  rotorcraft  digital  advanced 

avionics  ayataa  (ROOAAS)  to  transfer  the  technology 
developed  for  general  aviation  in  the  Demonstration 
Advanced  Avionics  System  (DAAS)  program  to 
rotorcraft  operation  was  undertaken.  The  ooject tve 
was  to  develop  an  integrated  avionics  system  design 
that  enhances  rotorcraft  single  pilot  IFR  operations 
without  Increasing  the  required  pilot 
tralnlng/exper lance  by  exploiting  advanced 
technology  In  computers,  busing,  displays  and 
integrated  systems  design.  A  key  element  of  the 
avionics  system  is  the  functionally  distributed 
architecture  that  has  the  potential  for  high 
reliability  with  low  weight,  power  and  cost.  A 
functional  description  of  the  RODAAS  hardware  and 
software  functions  Is  presented. 

-12-  466401  C.NTIS 

Tltre  anglais  :  Proceedings  of  the  Technical  Forum  (3rd)  on  the  F-16 
MIL-STD- 17504  Microprocessor  and  the  F-i8 
M1L-STD-1S89B  Compiler  Held  at  wright-Patterson  AFB, 
OH  on  May  5-6,  1982.  Volume  2.  Specifications. 

Auteurs  :  PESLER  J.  L. ;  SHOULDERS  D. 

Organisms  auteur:  Aeronautical  Systems  Dlv.,  Wright-Patterson  AFB,  OH. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  ASD-TR-82-501 1-V0L-2 

Source  :  see  also  volume  1,  AD-A150  583.;  NP.  547;  NTIS 

prices:  PC  A23/MF  A01 ;  DP.  6  May  82 

Resume  :  Contents:  Critical  Item  Development  Specification 

for  MIL-STD-1750A  Microprocessors  16ZE181 
(Preliminary);  Avionic  Processor  Standard 
Instruction  Set  Architecture  Requirements  16PP379A; 
Interim  Processor  Design  Requirements  16PP456 
(Draft);  Computer  Program  Development  Specification 
for  the  F-16  Integrated  JOVIAL  J-73  Support  Software 
System  16ZE165:  Dual  MI L-STD- 1 750A  Assembly  Syntax 
for  F-18A  S  Integrated  Support  Software  System;  Dual 
users  Manual. 

-13-  466400  C.NTIS 

Tltre  anglais  :  Proceedings  of  the  Technical  Forum  (3rd)  on  the  F-16 
MIL-STO-1750A  Microprocessor  and  the  F-16 
MIL-ST0-1589B  Compiler  Held  at  Wright-Patterson  AFB. 
OH  on  May  5-6,  1982.  Volume  1.  Papers. 

Auteurs  :  PESLER  J.  L. ;  SHOULDERS  D. 

Organism  auteur:  Aeronautical  Systems  Dlv. ,  Wright-Patterson  AFB,  oh. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  ASD-TR-82-501 1 -VOL- 1 

Source  :  See  also  Volume  2,  AD-A150  584.;  NP.  547;  NTIS 

prices:  PC  423/MF  401;  DP.  6  May  82 

Resum  :  Contents:  MI L-STD- 1750A  Microprocessor:  Management 

Overview;  Program  Overview;  Functional  and  technical 
description;  Applications  and  hardware;  Test  and 
evaluation  equipment;  Interim  processor  transition; 
F-16  MIL-STD-1589B  compiler;  Fairchild  marketing 
approach;  Life  cycle  cost  analysis;  MIL-STD-1750A; 
Managing  the  standard;  Transition  plan  to  upgrade 
the  digital  integrating  subsystem  to  MIL-STD-1750A 
for  MRASM;  wasp  weapon  system/’dlgltal  processing; 

Del co  electronics  MI L-STD- 1750A  architecture 
computer  family;  A  new  si  1 Icon-on-sapphlre 
MIL-STD-1750A  microprocessor ;  Texas  instruments 
VHSIC  MIL-STD-1750A  microprocessor;  Testability 
support  system  for  1750A:  In<clrcult  fault 
simulator;  Embedded  computer  standardlzat ion  program 
office  (ECSPO);  An  Implementation  of  a  1750  computer 
and  its  working  environment;  Support  of  software 
tools;  Use  of  the  1750A  support  software  on  an  IBM 
3033  under  MV/CMS;  The  AFWAL  MIL-STD- 15898  Jovial 
compl ler. 

-14-  412427  C.NTIS 

Tltre  anglais  :  Definition,  Analysis  and  Development  of  an  Optical 
Data  Distribution  Network  for  Integrated  Avionics 
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and  Control  Systems.  Part  2:  Component  Development 
and  System  Integration. 

Auteurs  :  YEN  H.  W.  .-  MORRISON  R.  J. 

Organlsme  auteur:  Hughes  Research  Labs..  Malibu.  CA. 'National 

Aeronautics  and  Space  Administration,  Washington. 

DC. 

Type  Document  -.  Report 

RPT.CTR.GRT  :  RPT  NAS  1.26:172429;  CTR  NAS1-15829 

Source  :  Final  Report,  1  May  1979  -  31  Mar.  1964.;  NP.  80; 

NT IS  Prices:  PC  A05/MF  A01 ;  Monitor  NASA-CR- 172429 ; 
DP.  dun  84 

Resume  :  Fiber  optic  transmission  Is  emerging  as  an 

attractive  concept  in  data  distribution  onboard 
civil  aircraft.  Development  of  an  Optical  Data 
Distribution  Network  for  Integrated  Avionics  and 
Control  Systems  for  commercial  aircraft  will  provide 
a  data  distribution  network  that  gives  freedom  from 
EMI-RFI  and  ground  loop  problems,  eliminates 
crosstalk  and  short  circuits,  provides  protection 
and  immunity  from  lightning  Induced  transients  and 
give  a  large  bandwidth  data  transmission  capability. 
In  addition  there  Is  a  potential  for  significantly 
reducing  the  weight  and  Increasing  the  reliability 
over  conventional  data  distribution  networks, 
wavelength  Division  Multiplexing  (WDM)  is  a 
candidate  method  for  data  communication  between  the 
various  avionic  subsystems.  With  WDM  all  systems 
could  conceptually  communicate  with  each  other 
without  time  sharing  and  requiring  complicated 
coding  schemes  for  each  computer  and  subsystem  to 
recognize  a  message.  However,  the  state  of  the  art 
of  optical  technology  limits  the  application  of 
fiber  optics  in  advanced  Integrated  avionics  and 
control  systems.  Therefore,  it  is  necessary  to 
address  the  architecture  for  a  fiber  optics  data 
distribution  system  for  Integrated  avionics  and 
control  systems  as  well  as  develop  prototype 
components  and  systems. 


-15-  409485  C.NTIS 

Tltre  anglais  :  Software  Control  and  System  Configuration 
Management:  A  Systems-Wlde  Approach. 

Ref.  Conference  ;  Previously  Announced  in  Iaa  as  A84-26713.  Prepared 
In  Cooperation  with  NASA.  Ames  Research  Center, 
Moffett  Field,  Calif.  Presented  at  lEEE/Alaa  5th 
Digital  Avionics  Systems  Conf.,  Seattle,  31  Oct.  -  3 
Nov  1983 

Auteurs  :  PETERSEN  K.  L. ;  FLORES  C. 

Organlsme  auteur;  National  Aeronautics  and  Space  Administration, 

Edwards,  CA.  Hugh  L.  Dryden  Flight  Research  Center. 

Type  Document  :  Conference 

RPT.CTR.GRT  ;  RPT  NAS  1.15:85908;  RPT  H-1256 

Source  :  NP.  21;  NTIS  Prices:  PC  A02/MF  A01 ;  Monitor 

NASA-TM-B5908 ;  DP.  Aug  84 

Resume  :  A  comprehensive  software  control  and  system 

configuration  management  process  for  flight-crucial 
digital  control  systems  of  advanced  aircraft  has 
been  developed  and  refined  to  insure  efficient 
flight  system  development  and  safe  flight 
operations.  Because  of  the  highly  complex 
interactions  among  the  hardware,  software,  and 
system  elements  of  state-of-the-art  digital  flight 
control  system  designs,  a  systems -wide  approach  to 
configuration  control  and  management  has  been  used. 
Specific  procedures  are  implemented  to  govern 
discrepancy  reporting  and  reconciliation,  software 
and  hardware  change  control,  systems  verification 
and  validation  testing,  and  formal  documentation 
requirements.  An  active  and  knowledgeable 
configuration  control  board  reviews  and  approves  all 
flight  system  configuration  modifications  and 
revalldatlon  tests.  This  flexible  process  has  proved 
effective  during  the  development  and  flight  testing 
of  several  research  aircraft  and  remotely  piloted 
research  vehicles  with  digital  flight  control 
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systems  that  ranged  from  relatively  simple  to  highly 
complex,  integrated  mechanizations. 

-16-  409482  C.NTIS 

Tltre  anglais  :  Software  Modifications  to  the  Demonstration  Advanced 
Avionics  Systems  (DAAS). 

Auteurs  :  NEDELL  B.:  HARDY  G. 

Organlsme  auteur.-  National  Aeronautics  and  Space  Administration, 

Moffett  Field,  CA.  Ames  Research  Center. 

Type  Document  :  Report 

RPT ,CTR , GRT  :  RPT  NAS  1.15:85942;  RPT  A-9713 

Source  :  NP.  36;  NTIS  Prices;  PC  A03/MF  A01 ;  Monitor 

NASA-TM-B5942;  DP.  Aug  84 

Resume  ;  Critical  Information  required  for  the  design  of 

integrated  avionics  suitable  for  generation  aviation 
is  applied  towards  software  modifications  for  the 
Demonstration  Advanced  Avionics  System  (DAAS).  The 
program  emphasizes  the  use  of  data  busing, 
distributed  microprocessors,  shared  electronic 
displays  and  data  entry  devices,  and  improved 
functional  capability.  A  demonstration  advanced 
avionics  system  (DAAS)  Is  designed,  built,  and 
flight  tested  in  a  Cessna  402.  twin  engine,  general 
aviation  aircraft.  Software  modlf icat ions  are  made 
to  DAAS  at  Ames  concurrent  with  the  flight  test 
program.  The  changes  are  the  result  of  the 
experience  obtained  with  the  system  at  Ames,  and  the 
comments  of  the  pilots  who  evaluated  the  system. 

-17-  401600  C.NTIS 

Tltre  anglais  ;  Fault  Tolerant  Architectures  for  Integrated  Aircraft 
Electronics  Systems.  Task  2. 

Auteurs  :  LEVITT  K.  N. ;  MELLIAR  SMITH  P.  M. ;  SCHWARTZ  R.  L. 

Organlsme  auteur:  SRI  International.  Menlo  Park.  CA. ‘National 

Aeronautics  ana  Space  AOmlnlstrat ion,  Washington. 

DC. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  NAS  1.26:172282;  CTR  NAS  1-17067 

Source  :  Final  Report.;  NP.  96:  NTIS  Prices:  PC  A05/MF  A01 ; 

Monitor  NASA-CR- 172282;  DP.  Jun  84 

Resume  :  The  architectural  basis  for  an  advanced  fault 

tolerant  on-board  computer  to  succeed  the  current 
generation  of  fault  tolerant  computers  is  examined. 
The  network  error  tolerant  system  architecture  is 
studied  with  particular  attention  to  intercluster 
configurations  and  communication  protocols,  and  to 
refined  reliability  estimates.  The  diagnosis  of 
faults,  so  that  appropriate  choices  for 
reconfiguration  can  be  made  Is  discussed.  The 
analysis  relates  particularly  to  the  recognition  of 
transient  faults  In  a  system  with  tasks  at  many 
levels  of  priority.  The  demand  driven  data-flow 
architecture,  which  appears  to  have  possible 
application  in  fault  tolerant  systems  is  described 
and  work  Invest Igat Ing  the  feasibility  of  automatic 
generation  of  aircraft  flight  control  programs  from 
abstract  specifications  is  reported. 

-18-  397875  C.NTIS 

Tltre  anglais  ;  Quantum  Leap  in  Avionics. 

Ref.  Conference  :  This  article  is  from  'Proceedings  Papers  of  the  AFSC 
(Air  Force  Systems  Command)  Avionics  Standardlzat ion 
Conference  (2nd)  Held  at  Dayton,  Ohio  on  30 
Novemoer-2  December  1982.  Volume  2'.  AD-A142  777, 
0959-974. 

Auteurs  :  CANTRELL  W.  E. 

Organlsme  auteur:  General  Dynamics,  Fort  worth,  tx.  Fort  worth  Dlv. 

Type  Document  :  Conference 

Source  :  NP.  16;  NTIS  Prices:  PC  A02/MF  A01 ;  DP.  Nov  82 

Resume  ;  Current  standardization  levels  in  such  program  as 

the  F-16  are  providing  benefits  of  productivity  and 
growth  that  have  been  sign if  leant  in  the  success  of 
that  program.  The  ever- increasing  drive  to 
performance,  multi-use  systems  and  diverse  weapons 
has  heavily  taxed  current  avionic  resources.  In 
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addition,  the  data  transfer  requirement  is 
complicated  by  tne  high  speea  aata  flow  that  moaern 
computers  both  feea  on  an  proauce;  by  multiple 
source-multiple  Destination  viaeo  aistrlbutlon 
requirement;  the  neea  to  self-test  tne  system  to 
lower  levels;  ana  tne  aeslre  to  Dynamically 
reconfigure  from  a  failure.  Fortunately,  tne 
tecnnology  to  acnieve  solutions  to  tnese  new 
problems  Is  evolving  in  tne  VHSIC  ana  fiber  otplcs 
programs,  so  that  it  is  possible  to  rearcnitecture 
tne  system  at  the  moaule  level  as  opposea  to  tne  LRU 
level.  Moaule  level  standaraizat ion  around  a  small 
number  of  types  allows  a  large  number  of  system 
level  combinations  wnile  acnievlng  economies  of 
scale  at  tne  moaule  level.  Tne  usual  objection  to 
standardization,  tnat  it  freezes  innovation,  is 
avoiaea  by  technology  transparency  provisions;  wnile 
at  the  same  time  tne  objection  tnat  stanaaraizat ion 
obsoletes  tne  present  is  avoiaea  by  Downward 
compatibility  provisions.  Canaiaates  for 
stanaardizatlon  in  this  approach  include  bus 
Interfaces,  tne  system  network,  modules  ana  racks. 
(Author ) . 
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Tltre  anglais  :  PAVE  PILLAR:  A  Maturation  Process  for  an  Advanced 
Avionics  Architecture. 

Ref.  Conference  :  This  article  is  from  'Proceedings  Papers  of  tne  AFSC 
(Air  Force  Systems  Command)  Avionics  Standardization 
Conference  (2nd)  Held  at  Dayton.  Ohio  on  30 
November-2  December  1982.  Volume  2'.  AD-A1A2  777, 
P675-690. 

Auteurs  :  MORGAN  D.  R.;  BELLEM  R.  D. 

Organ isme  auteur:  Air  Force  wrlgnt  Aeronautical  Labs., 

Wright -Pat ter son  AFB,  OH. 

Type  Document  :  Conference 

Source  :  NP.  16;  NTIS  Prices:  PC  A02/MF  AOI ,  DP.  Nov  82 

Resume  :  Recent  speed  and  density  advancements  in 

microelectronics  will  now  permit  the  development  of 
powerful  and  affordable  avionic  architectural 
elements  -  viz.  processing,  memories  and  wide  band 
aata  buses.  An  advanced  architecture  making  use  of 
tnese  elements  and  coupled  with  highly  flexible 
software,  will  enhance  the  capability  to  fully 
exploit  Information  integration  and  automation 
processes.  An  abundance  of  real-time  data  is 
available  for  Integration  from  diverse  subsystems 
aboard  advanced  military  aircraft.  Dramatic 
Improvements  In  avionic  system  availability,  crew 
workload  reduction,  weapon  system  survlvabl l ity  and 
supportabl 1 Ity  are  possible  using  this  approach.  The 
Introduction  of  tnese  system  Integration 
technologies  into  the  force  structure  is  needed  at 
tne  earliest  opportunity  to  meet  expanding  mission 
requirements.  However,  care  must  be  exercised  to 
ensure  tnat  concepts  and  standards  nave  been  matured 
through  validation  testing  to  avoid  potentially 
costly  mistakes.  The  Air  Force  has  estabiisna  tne 
PAVE  PILLAR  Program  to  provide  the  need  maturation 
of  advanced  avionic  system  architectural  approaches, 
system  elements  and  potential  system  standards 
during  advanced  development.  This  Program  also 
initiates  the  concept  of  establishing  system 
Integration  technology  as  a  separate  discipline 
within  the  Laboratory  framework.  Tnls  paper 
describes  the  PAVE  PILLAR  Program  being  pursued 
within  the  Avionics  Laboratory  of  the  Wright 
Aeronautical  Laboratories.  Enhancements  to 
operational  force  effectiveness  resulting  from 
system  integration  will  be  described,  along  with 
advanced  system  tecnnology  elements  and  potential 
standards  which  will  De  developed  and  demonstrated. 
(Author ) . 
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-20-  397857  C.NTIS 

Tltre  anglais  :  Elements  for  Successful  Implementation  of  Computing 
Standards. 

Ref.  Conference  :  This  article  is  from  'Proceedings  Papers  of  the  AFSC 
(Air  Force  Systems  Command)  Avionics  Standardtzat ion 
Conference  (2nd)  Held  at  Dayton,  Ohio  on  30 
Novem0er-2  Oecemper  1982.  Volume  2',  AD-A 142  777, 
P643-653. 

Auteurs  :  ENGLAND  G.  R. 

Organisme  auteur:  General  Dynamics,  Fort  North,  Tx.  Fort  North  Div. 

Type  Oocument  :  Conference 

Source  :  NP.  11;  NT IS  Prices:  PC  A02/MF  A01 ;  OP.  Nov  82 

Resume  :  The  F - 16  avionics  implements  what  is  likely  the 

Droadest  application  of  standards  of  any  USAF  weapon 
system.  Standards  available  in  1976  were  applied 
which  consisted  of  the  MIL-STD-1553  Multiple*  Data 
Bus.  JOVIAL  J3B  which  was  the  defacto  software  HOL 
and  precursor  to  JOVIAL  J73  dialect  and  the 
MIL-STD-483/490  software  documentation  standard. 
These  standards  were  Instrumental  in  making  the  F-16 
a  very  successful  program.  The  F-16  avionic  system 
is  now  being  greatly  expanded  to  accommodate 
advanced  sensors  and  weapons  currently  in  USAF 
funded  development.  Once  again  the  F-16  is  at  the 
forefront  in  implementing  the  latest  USAF  standards. 
A  key  feature  of  the  enhanced  avionics  is  the 
application  of  JOVIAL  J73  (MIL-STD-1589B)  for  all 
subsystem,  the  MIL-STD-1553B  Multiplex  Data  Bus,  the 
MIL-ST0-175OA  Computer  Instruction  Set  Architecture 
and  the  MIL-ST0-176O  Stores  Interrface.  This  paper 
describes  the  implementation  of  standards  in  both 
the  current  and  the  enhanced  F-16  avionics. 

(Author) . 
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Tltre  anglais  :  Common  15538  I/O  Channel  for  the  F-16. 

Ref.  Conference  :  This  article  is  from  'Proceedings  Papers  of  the  AFSC 
(Air  Force  Systems  Command)  Avionics  Standardization 
Conference  (2nd)  Held  at  Dayton,  Ohio  on  30 
November-2  December  1982.  Volume  1',  AD-A142  776. 
P367-382. 

Auteurs  :  ALFORD  S. 

Organisme  auteur:  General  Dynamics,  Fort  North,  TX.  Fort  North  Div. 

Type  Document  :  Conference 

Source  :  NP.  16;  NTIS  Prices:  PC  A02/MF  A01 ;  DP.  Nov  82 

Resume  :  The  1980's  will  see  Increased  standardization  in 

military  avionics.  MIL-STD-1553  has  proven  to  be  an 
effective  means  of  assuring  communications  among 
Independently  developed  avionic  subsystems.  Future 
applications  of  the  Air  Force  standard  computer 
architecture.  MIL-STD-1750A,  and  standard 
programming  language,  MIL-STD-1589B,  will  further 
decrease  the  life  cycle  costs  of  many  systems 
currently  under  development.  While  MIL-STD-1750A 
defines  a  specific  CPU  architecture,  and 
MIL-STD-1553B  defines  the  method  of  communication 
among  subsystems,  no  current  Air  Force  standard 
defines  the  I/O  channel  that  links  the  1750 
processor  to  the  1553  bus.  In  order  to  reduce  both 
the  cost  of  software  development  and  maintenance, 
General  Dynamics  has  developed  a  1553  channel 
architecture  to  be  applied  to  all  the  subsystems 
being  programmed  In-house  for  the  F-16 
Multi-National  Staged  Improvement  Program  (MSIP). 
(Author) . 
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Tltre  anglais  :  Multiple  System  OFP  Support  (MSOS)  System,  a 
Pre-PMRT  Capability  for  Evaluating  Tactical 
Software. 

Ref.  Conference  :  This  article  is  from  'Proceedings  Papers  of  the  AFSC 
(Air  Force  Systems  Command)  Avionics  Standardization 
Conference  (2nd)  Held  at  Dayton,  Ohio  on  30 
November-2  December  1982.  Volume  t'.  AD-A 142  776, 
065-92. 
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KIRCHOFF  M. ;  VAJO  V.;  LOWERY  H. 

Intermetrics,  Inc.,  Huntington  Beach,  CA. 

Conference 

NP.  8;  NTIS  Prices:  PC  A02/MF  AOI;  DP.  Nov  82 
A  generic  software  testing  facility  Is  presently 
under  development  at  Warner-Roblns  Air  Logistics 
Command.  The  Multiple-System  OFP  Support  System  win 
allow  independent  verification  and  validation  of 
avionic  software  for  a  variety  of  systems  to  be 
conducted  early  in  the  development  cycle,  reducing 
costs  to  the  Air  Force.  Intermetrics,  Inc.  Is 
linking  via  Hardware  and  associated  software  tne 
Nanodata  QM-1  mlcroprogrammable  computer  and  tne 
VAX-11/7B0.  The  AM-l  hosts  emulations  of  tactical 
embedded  computers  and  the  VAX  hosts  simulations  of 
real  environments.  Overlaying  the 
emulat lon/slmulat ion  system  In  a  UNIX-based  monitor 
tailored  to  provide  absolute  control  and  complete 
visibility  Into  tne  executing  target  machine 
software.  A  variety  of  static  test  tools  for 
analyzing  JOVIAL  and.  eventually.  Ada  code  is  being 
nosted  on  the  VAX,  A  primary  function  of  these  tools 
will  be  to  verify  the  conformance  of  the  code  to  the 
specific  standards.  (Author). 

-23-  378338  C.NTIS 

Tltre  anglais  :  Development  of  a  Redundant  Computer  System  for 
Flight  Augmentation. 

Auteurs  :  HERRSCHER  G. ;  KIRST  B.;  SCHMIDT  D. ;  SZLACHTA  J. 

Organlsme  auteur:  Litton  Technlsche  werke,  Freiburg  1m  Breisgau 

(Germany,  F . R. ) . *Nat Iona  1  Aeronautics  and  Space 
Administration,  Washington,  DC. 

Type  Document  :  Report 

:  RPT  BMFT-FB-W-83-027 

:  Final  Report,  Apr.  1983.;  In  German;  English 
Summary.  Sponsored  by  Bundesmlnlsterlum  fuer 
Forschung  und  Technologic. ;  NP.  130:  NTIS  Prices:  PC 
A07/MF  AOI;  DP.  Oct  83 

:  A  fault-tolerant  airborne  computer  system  for 
time-critical  process  control  applications  Is 
described.  It  guarantees  real-time  processing 
continuity  in  the  event  of  hardware  failures.  The 
redundancy  Is  hierarchically  graded.  The  structure 
comprises  a  bus-coupled  homogenous  multicomputer 
system  based  on  a  redundant  modular  design.  Fault 
detection  techniques,  fault  diagnosis, 
reconfiguration,  and  development  of  process  control 
and  communication  In  a  decentral ly  organized 
multiprocessor  system  are  discussed.  The  design  of  a 
functional  model  and  reliability  estimates  are 
outl ined. 
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Tltre  anglais  :  Development  and  Analysis  of  the  Software  Implemented 
Fault-Tolerance  (SIFT)  Computer. 

Auteurs  :  GOLDBERG  J.;  KAUTZ  W.  H. ;  MELLIAR  SMITH  P.  M. ;  GREEN 

M.  W. ;  LEVITT  K.  N. 

Organlsme  auteur:  SRI  International,  Menlo  Park,  CA. ‘National 

Aeronautics  and  Space  Administration,  Washington, 

DC. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  NAS  1.26:172146;  CTR  NAS1-15428 

Source  :  .’Inal  Report.:  NP.  209;  NTIS  Prices:  PC  A10/MF  AOI; 

Monitor  NASA-CR-172148;  DP.  Feb  84 

Resume  :  SIFT  (Software  Implemented  Fault  Tolerance)  Is  an 

experimental,  fault-tolerant  computer  system 
designed  to  meet  the  extreme  reliability 
requirements  for  safety-critical  functions  In 
advanced  aircraft.  Errors  are  masked  by  performing  a 
majority  voting  operation  over  the  results  of 
Identical  computations,  and  faulty  processors  are 
removed  from  service  by  reassigning  computations  to 
the  nonfaulty  processors.  This  scheme  has  been 
Implemented  In  a  special  architecture  using  a  set  of 
standard  Bend lx  BDX930  processors,  augmented  by  a 
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special  asynchronous-broadcast  communlcat Ion 
Interface  tnat  provides  direct,  processor  to 
processor  communication  among  all  processors.  Fault 
Isolation  is  accomplished  in  hardware;  all  other 
fault-tolerance  functions,  together  with  scheduling 
and  synchronization  are  Implemented  exclusively  by 
executive  system  software.  The  system  reliability  Is 
predicted  by  a  Markov  model.  Mathematical 
consistency  of  the  system  software  with  respect  to 
the  reliability  model  has  been  partially  verified, 
using  recently  developed  tools  for  machine-aided 
proof  of  program  correctness. 


-25-  374287  C.NTIS 

Tltre  anglais  :  Integration  of  ICNIA  (Integrated  Communications 
Navigation  and  Identification  Avionics)  into 
Advanced  High  Performance  Fighter  Aircraft. 

Ref.  Conference  :  This  article  is  from  'Advanced  Concepts  for 

Avionics/Weapon  System  Design.  Development  and 
Integration;  Conference  Proceedings  of  the  Avionics 
Panel  Symposium  (45th)  Held  at  Ottawa.  Canada  on 
18-22  April  1983, '  AD-A138  600,  P26-1-26-8. 

Auteurs  :  CONRAD  E.  R. 

Drganlsme  auteur:  General  Dynamics,  Fort  Worth,  TX.  Fort  Worth  Dlv. 

Type  Document  :  Conference 

Source  :  NP .  8;  NT  IS  Prices:  PC  A02/MF  A01;  DP.  Oct  83 

Resume  :  The  use  of  ICNIA  will  significantly  improve  the 

avionics  suites  of  military  aircraft.  Advantages  of 
ICNIA  Include:  Reduction  in  space,  weight,  power  and 
cooling  reoulrements;  Increase  in  reliability  and 
maintainability;  Decrease  in  life  cycle  cost;  Ease 
of  integration  into  an  avionics  suite  via  a 
multiplex  PUS;  and  Reconfigurability.  To  take 
advantage  of  these  features,  certain  design 
guidelines  should  be  followed.  The  basic  guideline 
Is  that  the  alrframer  should  control  the  integration 
of  any  subsystem  into  his  avionics  suite.  This 
Implies  that  the  ICNIA  Interface  software,  and 
possibly  some  of  the  hardware,  must  be  In  accordance 
with  the  Integration  philosophies  cl  the  host 
platform.  These  philosophies  will  vary  from  one 
accordance  with  the  Integration  philosophies  of  the 
host  platform  to  the  other.  General  Dynamics  has  an 
Integration  and  partitioning  concept  which  has 
functioned  exceptionally  well  on  the  F-16.  Each 
subsystem  should  perform  its  entire  task  and  the 
Interfaces  between  subsystems  should  be  as  simple  as 
possible.  This  concept  has  three  major  advantages: 
Changes  to  one  subsystem  are  transparent  to  other 
subsystems  and  do  not  result  in  changes  being 
required  In  other  subsystems  when  one  subsystem  is 
changed;  The  Integration  of  a  new  subsystem  Into  the 
avionics  suite  Is  not  difficult  since  a  new  system 
does  not  require  unique  support  of  other  subsystems; 
and  Fault  Isolation  is  simple  since  each  subsystem 
performs  an  entire  task. 
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Practical  Approach  to  the  Design  of  a  New  Avionic 
System. 

This  article  is  from  'Advanced  Concepts  for 
Avionics/Weapon  System  Design,  Development  and 
Integration:  Conference  Proceedings  of  the  Avionics 
Panel  Symposium  (45th)  Held  at  Ottawa.  Canada  on 
18-22  April  1983,'  AD-A138  600,  P25-1-25-11. 

DUKE  P.  A. 

British  Aerospace  Public  Ltd.,  Co.,  Brough 
(England).  Klngston-Brougn  Dlv. 

Conference 

NP.  11;  NTIS  Prices:  PC  A02/MF  A01 ;  DP.  Clct  83 
This  paper  describes  a  program  to  design,  construct 
and  demonstrate  an  advanced  avionic  system  for  the 
next  generation  of  tactical  combat  aircraft.  British 
Aerospace  Is  carrying  out  such  a  program  with  the 
objective  of  reducing  development  risks  associated 
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with  the  rapid  advance  of  technology.  A  number  of 
factors  contribute  to  this  risk,  notably  the 
dramatic  increase  in  system  capability  made  possible 
by  the  general  availability  of  LSI  and  VLSI 
circuitry.  This  has  occurred  at  a  time  when  the  next 
aircraft  project  is  likely  to  have  a  single  seat 
cockpit.  Traditionally  independent  systems  can  now 
be  linked  using  a  data  bus  to  provide  a  fully 
Integrated  system  with  the  pilot's  needs  foremost  In 
mind.  The  system  is  based  on  a  multi  bus 
architecture  recognising  the  differing  integrity 
repulrements  of  different  parts  of  the  system.  A 
complete  aircraft  system  is  represented,  divided 
Into  functional  groups,  and  Includes  the  basic 
aircraft  systems  such  as  hydraulics  and  fuel 
management  and  an  Integral  maintenance  reporting 
system.  Mission  systems  include  a  wide  range  of 
sensor  and  weapon  types.  The  practical  implications 
of  Introducing  Mil. Std. 1760  or  the  associated  STANAG 
3637AA  standard  store  Interfaces  are  being  studied. 
The  avionic  systems  are  linked  to  an  advanced 
cockpit,  with  the  objective  of  reducing  pilot 
workload.  The  cockpit  makes  use  of  mu  ''-purpose 
displays  and  an  integrated  approach  to  s  s:  -> 
control.  A  display  of  the  out -of -cockpit  a_ene  Is 
provided  to  allow  the  'pilot'  to  operate  the 
controls  In  a  realistic  manner  and  so  provide 
representative  input  to  the  avionic  system. 
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Network  Communications  for  a  Distributed  Avionics 
System. 

This  article  Is  from  'Advanced  Concepts  for 
Avionics /weapon  System  Design,  Development  and 
Integration:  Conference  Proceedings  of  the  Avionics 
Panel  Symposium  (45th)  Held  at  Ottawa,  Canada  on 
18-22  April  1983,'  AD-A138  600,  P19-1-19-10. 

OSTGAARD  J.  C.;  ZANN  D.  A. 

Air  Force  Avionics  LaD.,  Wrlght-Patterson  AFB,  Oh. 
Conference 

NP.  10;  NTIS  Prices:  PC  A02/MF  A01 ;  DP.  Oct  83 
Due  to  the  postulated  1990's  threat  environment 
advanced  avionics  architectures  are  experiencing 
demands  for  increased  performance  which  have  led,  in 
part,  to  increased  processing  reoulrements  and 
system  complexity.  As  more  processors  are  added  to 
the  control  environment  of  sophisticated  military 
aircraft,  the  choice  of  processor  Interconnection 
topology,  and  methodology  assumes  greater 
importance.  This  choice  profoundly  Influences 
information  throughput,  reliability,  survivability 
and  Integrity  throughout  the  weapon  system.  The 
ability  to  rapidly  exchange/transfer  information 
among  processors  and  devices  Is  critical  if  one  is 
to  develop  a  reliable,  effective  communication 
system.  This  caper  addresses  basic  communication 
techniques  which  could  serve  as  candidates  in 
satisfying  the  network  communication  requirements  of 
an  advanced  avionics  architecture.  Features  of  each 
technique  are  examined  to  ascertain  the  performance 
of  these  multi -access  protocols  in  terms  of 
developed  system-driven  criteria.  (Author). 


-28-  374267  C.NTIS 

Titre  anglais  :  System  Architecture-,  key  to  Future  Avionics 
Capabi lit  tes . 

Ref.  Conference  :  This  article  is  from  'Advanced  Concepts  for 

Avionics/weapon  System  Design,  Development  and 
Integration:  Conference  Proceedings  of  the  Avionics 
Panel  Symposium  (45th)  Held  at  Ottawa,  Canada  on 
18-22  April  1983,'  AD-A138  600,  pl-1-1-6. 

Auteurs  :  ENGLAND  G.  R. 

Organlsme  auteur:  General  Dynamics,  Fort  North.  TX.  Fort  North  Dlv. 
Type  Document  :  Conference 

Source  :  NP.  6;  NTIS  Prices:  PC  A02/MF  A01 ;  DP.  Oct  83 


B-22 


COMPUTING  SYSTEM  CONFIGURATIONS  FOR  HIGHLY 
INTEGRATED  GUIDANCE  AND  CONTROL  SYSTEMS 


Resume  :  Appropriate  architectural  approaches  In  the 

physical,  functional,  information  transfer,  and 
control  system  areas  are  the  Key  to  future  avionic 
capabilities.  The  appropriate  architectures  Hill 
provide  dramatic  1 mprovement s  In  system  performance 
while  simultaneously  Improving  system  availability, 
supportabl 1 Ity,  and  affordability.  The  software  and 
hardware  technology  required  to  achieve  these 
architectural  Improvements  are  already  here  and 
simply  need  to  be  Improved,  properly  applied,  and 
Integrated.  The  resulting  weapon  systems  will, 
however,  nave  widespread  effects  In  many  areas  of 
operations,  logistics,  and  equipment  acquisition. 
Changes  will  be  required  In  the  way  pilots  are 
trained  and  conduct  their  missions.  The  proper 
pi  lot/vehicle  Interface  will  need  to  be  developed  to 
fully  allow  the  pilot  to  act  as  a  system  manager.  At 
the  same  time  data  must  be  provided  to  assure  pilot 
confidence  that  the  automated  system  Is 
accomplishing  properly  the  detailed  operational 
tasks  which  were  formerly  accomplished  manually. 
Procurement  of  avionic  systems  and  spares  will 
undergo  a  dramatic  change.  Common  modules  will 
likely  to  De  procured  directly  by  the  military  from 
software  and  hardware  module  sources  and  will  be 
provided  to  avionic  vendors.  Avionic  systems 
developers  will  find  themselves  creating  special 
sensor  and  effector  modules  and  function-unique 
software  to  be  used  with  modules  common  to  many 
other  uses.  With  large  numbers  of  throwaway  modules, 
depot  repair  facilities  and  organizations  will 
shrink,  or  the  function  will  revert  to  the  original 
manufacturer. 
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Tltre  anglais  :  Study  of  Optimal  Computer  Network  Architecture  for 
Digital  Avionics  Systems. 

Auteurs  :  KRILIC  M.  F. 

Organlsme  auteur:  Air  Force  Inst,  of  Tech..  Wright-Patterson  afb.  Oh. 
School  of  Engineering. 

Type  Document  :  Thesis 

RPT.CTR.GRT  :  RPT  AFIT/GE/EE/83D-36 

Source  :  Master's  thesis;  NP.  221;  NTIS  Prices:  PC  aio/mf 

A01 ;  OP.  Dec  83 

Resume  :  In  this  paper,  current  theoretical  considerations  in 

available  literature  have  been  used  to  sort  out  the 
essential  figures  of  merit  of  computer  network 
architectures  for  digital  avionic  systems.  Fourteen 
different  approaches  to  the  same  problem  of  data 
multiplexing  In  avionics  systems  are  analyzed 
according  to  the  key  issues.  Conclusions  drawn  are 
used  to  define  the  optimal  computer  network 
architecture  for  digital  avionics.  The  Self-Managing 
Multiplex  System  (SMS)  Is  conceptually  designed  with 
respect  to  the  optimal  characteristics,  along  with 
the  discussions  of  some  trade-offs  that  had  to  be 
made.  The  burst  errors  sel f -correct Ing  feature  of 
the  broadcast -acknowledgements  In  the  SMS  concept 
seems  to  deserve  some  sort  of  testing  In  practlce. 

It  is  recommended  that  a  detailed  simulation  study 
should  be  performed  later  and  a  hot  bench  built  up 
using  the  latest  technologies  that  exist.  (Author). 


-30-  362558  C.NTIS 

Tltre  anglais  :  Design  Implications  from  Aftl/F-,'6  Flight  Test. 
Ref.  Conference  ;  Presented  at  Iee/Alaa  5TH  Digital  Avionics  Systems 
Conf.,  Seattle,  31  Oct.  -  3  Nov.  1983. 

Auteurs  :  ISHMAEL  S.  D.;  REGENIE  V.  A.;  MACKALL  D.  A. 

Organlsme  auteur:  National  Aeronautics  and  Space  Administration, 
Moffett  Field,  CA.  Ames  Research  Center. 

Type  Document  :  Conference 

RPT.CTR.GRT  :  RPT  NAS  1.15:86026;  RPT  H-1213 

Source  :  Final  Report.;  NP.  13;  NTIS  Prices:  PC  A02/MF  A01; 

Monitor  NASA-TM-86026;  DP.  Jan  84 
Resume  :  Advanced  fighter  technologies  are  evolving  into 
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highly  complex  systems.  Flight  controls  ere  being 
integrated  with  advanced  avionics  to  achieve  a  total 
system.  The  advanced  flgnter  technology  integration 
(AFTI)  F-16  aircraft  is  an  example  of  a  highly 
complex  digital  flight  control  system  integrated 
Mlth  advanced  avionics  and  cockpit.  The  architecture 
of  these  nee  systems  Involves  several  general 
issues.  The  use  of  dissimilar  backup  modes  if  the 
primary  system  falls  requires  the  designer  to  trade 
off  system  simplicity  and  capability.  This  tradeoff 
Is  evident  In  the  AFTI/F-16  aircraft  with  Its 
limited  stability  and  fly-by-wire  digital  flight 
control  systems.  In  case  of  a  generic  software 
failure,  the  backup  or  normal  mode  must  provide 
equivalent  envelope  protection  during  the  transition 
to  degraded  flight  control.  The  complexity  of 
systems  like  the  AFTI/F-lB  system  defines  a  second 
design  issue,  which  can  De  divided  into  two 
segments:  the  effect  on  testing,  and  the  pilot’s 
ability  to  act  correctly  In  the  limited  time 
available  for  cockpit  decisions.  The  large  matrix  of 
states  possible  with  the  AFTI/F-16  flight  control 
system  illustrates  the  difficulty  of  both  testing 
the  system  and  choosing  real-time  pilot  actions. 

-31-  350142  C.NTIS 

Titre  anglais  :  Fault  Tolerant  Architectures  for  Integrated  Aircraft 
Electronics  Systems. 

Auteurs  :  LEVITT  K.  N. ;  MELLIAR  SMITH  P.  M. :  SCHWARTZ  R.  L. 

Organlsme  auteur:  SRI  International.  Menlo  Park,  CA. ‘National 

Aeronautics  and  Space  Administration,  Washington, 

DC. 

:  Report 

:  RPT  NAS  1.26:172226:  CTR  NAS1-17067;  CTR  SRI  PROJ. 
4616 

:  Final  Report.;  NP.  57;  NTIS  Prices:  PC  A04/MF  A01 ; 

Monitor  NASA-CR- 172226;  DP.  Aug  B3 
:  Work  Into  possible  architectures  for  future  flight 
control  computer  systems  is  described.  Ada  for 
Fault-Tolerant  Systems,  the  NETS  Network 
Error-Tolerant  System  architecture,  and  voting  in 
asynchronous  systems  are  covered. 


Type  Document 
RPT.CTR.GRT 

Source 

Resume 


-32-  284125  C.NTIS 
Titre  anglais 
Auteurs 

Organlsme  auteur 


Type  Oocument 
RPT.CTR.GRT 

Source 


Resume 


Advanced  Flight  Control  System  Study. 

HARTMANN  G.  L.;  WALL  J.  E.  ;  RANG  E.  R. ;  LEE  H.  P.; 
SCHULTE  R.  W. 

Honeywell  Systems  and  Research  Center,  Minneapolis. 
MN. ‘National  Aeronautics  and  Space  Administration, 
Washington,  OC. 

Report 

RPT  NAS  1.26:163117;  RPT  H0NEYWELL-82SRC5 ;  CTR  NASA- 
2876 

Final  Report.;  Prepared  In  Cooperation  with 
Lockheed-Cai ifornla  CD.,  Burbank.;  NP.  171;  ntis 
Prices:  PC  A08/MF  A01 ;  Monitor  NASA-CR-1631 17 ;  DP. 
Nov  82 

A  fly  by  wire  flight  control  system  architecture 
designed  for  high  reliability  Includes  spare  sensor 
and  computer  elements  to  permit  safe  dispatch  with 
failed  elements,  thereby  reducing  unscheduled 
maintenance.  A  methodology  capable  of  demonstrat ing 
that  the  architecture  does  achieve  the  predicted 
performance  characteristics  consists  of  a  hierarchy 
of  activities  ranging  from  analytical  calculations 
of  system  reliability  and  formal  methods  of  software 
verification  to  Iron  bird  testing  followed  by  flight 
evaluation.  Interfacing  this  architecture  to  the 
Lockheed  S-3A  aircraft  for  flight  test  Is  discussed. 
This  testbed  vehicle  can  be  expanded  to  support 
flight  experiments  In  advanced  aerodynamics, 
electromechanical  actuators,  secondary  power 
systems,  flight  management,  new  displays,  and  air 
traffic  control  concepts. 
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-33-  273565  C.NTIS 

litre  anglais  :  Demonstration  Advanced  Avionics  System  (Daas) 
Function  Description. 

Auteurs  :  BAILEY  A.  J.;  BAILEY  0.  G. ;  GAABO  R.  J.;  LAHN  T.  G. ; 

LARSON  J.  C. 

Organisms  auteur :  Honeywell.  Inc.,  Minneapolis,  MN. ’National 

Aeronautics  and  Space  Administration,  Washington, 

DC. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  NAS  1.26:166282;  CTR  NAS2-10021 

Source  ;  Prepared  In  Cooperation  with  King  Radio  Corp. . 

Olathe,  Kans.;  np.  204;  ntis  Prices-.  PC  aio/mf  aoi  ; 
Monitor  NASA-CR- 1 662B2 ;  DP.  Jan  82 

Resume  :  The  Demonstration  Advanced  Avionics  System,  DAAS,  is 

an  Integrated  avionics  system  utilizing 
microprocessor  technologies,  data  Dusing,  and  shared 
displays  for  demonstrating  the  potential  of  these 
technologies  In  Improving  the  safety  and  utility  of 
general  aviation  operations  In  the  late  1980's  and 
oeyond.  Major  hardware  elements  of  the  DAAS  include 
a  functionally  dlstrlputed  microcomputer  complex,  an 
integrated  data  control  center,  an  electronic 
horizontal  situation  indicator,  and  a  radio  adaptor 
unit.  AH  processing  and  display  resources  are 
interconnected  by  an  IEEE-488  bus  in  order  to 
enhance  the  overall  system  effectiveness, 
reliability,  modularity  and  mamtainabl  l  ity.  A 
detail  description  of  the  DAAS  architecture,  the 
OAAS  hardware,  and  the  DAAS  functions  is  presented. 
Tne  system  Is  designed  for  installation  and  flight 
test  in  a  NASA  Cessna  402-B  aircraft. 

-34-  250705  C.NTIS 

Tltre  anglais  :  An  Assessment  of  the  Real-Time  Application 
Capabilities  of  the  SIFT  Computer  System. 

Auteurs  :  BUTLER  R.  W. 

Organlsme  auteur:  National  Aeronautics  and  Space  Administration, 
Hampton,  VA.  Langley  Research  Center. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  NASA-TM-84482 ;  RPT  NAS  1.15:84482 

Source  :  NP.  17;  NTIS  Prices:  PC  A02/MF  AOI;  DP.  Apr  82 

Resume  :  The  real-time  capabilities  of  the  SIFT  computer 

system,  a  highly  reliable  multicomputer  architecture 
developed  to  support  the  flight  controls  of  a 
relaxed  static  stability  aircraft,  are  discussed. 

The  SIFT  computer  system  was  designed  to  meet 
extremely  high  reliability  requirements  and  to 
facilitate  a  formal  proof  of  its  correctness. 
Although  SIFT  represents  a  significant  achievement 
in  fault-tolerant  system  research  It  presents  an 
unusual  and  restrictive  Interface  to  its  users.  The 
characteristics  of  the  user  Interface  and  Its  impact 
on  application  system  design  are  assessed.  * 

-35-  242687  C.NTIS 

Tltre  anglais  :  Guidance  and  Control  Technology  for  Highly 
Integrated  Systems. 

Organlsme  auteur:  Advisory  Group  for  Aerospace  Research  and 

Development,  Neuilly-sur-Seine  (France) . ’Nat lonal 
Aeronautics  and  Space  Administration,  Washington, 

DC. 

Type  Document  :  Report 

RPT.CTR.GRT  :  RPT  AGARD-CP-314 

Source  :  In  English  and  French,  the  33RD  Symp.  Held  In 

Athens,  13-16  Oct.  1981.;  NP.  179;  NTIS  Prices:  PC 
A09/MF  AOI;  OP.  Feb  82 

Resume  :  No  abstract  available. 

-36-  223298  C.NTIS 

Tltre  anglais  :  Survivable  Avionics  Computer  System. 

Auteurs  :  MONSON  P.  R. ;  MONSON  C.  A.;  PEASE  M.  C. ;  WISCHMEYER 

C.  E. 

Organlsme  auteur:  SRI  Internet  tonal ,  Menlo  Park,  CA. 

Type  Document  :  Report 

RPT.CTR.GRT  :  CTR  F33615-80-C-1014 
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Source  :  Final  rept . ;  NP.  241;  NTIS  Prices:  PC  A11/MF  AOI ; 

DP.  Nov  80 

Resume  :  This  contract  has  shown  by  the  examples  of 

navigation  ana  flight  control  that  the  CHAMP 
approach  to  architecture  Design  can  be  applied  to 
avionic  computational  problems.  Furthermore,  the 
simulations  have  shown  that  CHAMP  can  provide  a 
potentially  survlvable  computer  for  aircraft  use. 
CHAMP  uses  a  simple  network  which  can  make  use  of 
advanced  hardware  techniques  (such  as  those 
available  through  tne  vhsic  program),  it  also 
simplifies  material  inventory  problems  since  there 
Is  only  one  type  of  spare  (a  single  PC)  which  is 
contained  In  a  single  chip.  The  PC  used  In  this 
study  is  well  within  tne  capability  of  single-chip 
techniques  projected  for  DAIS  the  1985  time  period. 
The  avionics  functions  software  used  in  this  study 
were  created  by  using  DAIS  project  personnel 
structured  programming  techniques  whlcn  yielded 
sub-modules  for  each  function  that  were  small  and 
tractable  and  easily  managed  by  microprocessor -based 
computers  of  modest  capability.  This  is  especially 
significant  considering  that  this  can  be 
accomplished  with  processors  operating  at  relatively 
low-frequency  clock  rates  (1  KHz  as  opposed  to  the 
10  to  20-MHz  clock  often  used  In  more  elaborate 
processors).  This  results  in  a  much  more  reliable 
and  easily  constructed  hardware  module  for  the 
computer.  Furthermore,  this  relative  simplicity 
tends  to  make  the  computing  modules  immune  to  noise, 
interference,  and  EMP. 


-37-  213697  C.NTIS 
Tltre  anglais 

Ref.  Conference  : 

Organ Isme  auteur: 

Type  Document 

RPT.CTR.GRT 

Source 

Resume 


Tactical  Airborne  Distributed  Computing  and 
Networks . 

Presented  at  a  Meeting  of  the  Avionics  Panel  Held  in 
Roeros,  Norway.  22-25  Jun  81. 

Advisory  Group  for  Aerospace  Research  and 
Development.  Neul l ly-sur-Seine  (France). 

Conference 
RPT  AGARD-CP-303 

Conference  proceedings.;  NP.  414;  NTIS  Prices:  PC 
A 18/MF  AOI ;  DP.  Oct  81 

These  proceedings  consist  of  the  papers  and 
discussions.  The  35  papers  were  divided  as  follows, 
three  on  state-of-the-art;  five  on  system 
architecture;  four  on  system  design  approaches;  five 
on  software;  five  on  fault  tolerance  and 
reliability;  six  on  interconnection,  bussing  and 
networking;  seven  on  applications  to  avionics 
systems . 


-38-  208935  C.NTIS 
Tltre  anglais 


Auteurs 

Organ isme  auteur 


Type  Oocument 
RPT.CTR.GRT 

Source 


Resume 


Digital  Avionics  Information  System  (DAIS): 
Development  and  Demonstration. 

COOK  M.  J.;  MASON  R.  C.;  STAUTBERG  J.  L. ;  SELF  L.  E. 

;  ELLISON  R.  L. 

TRW  Defense  and  Space  Systems  Group,  Redondo  Beach, 
CA . *Atr  Force  Wright  Aeronautical  Labs.. 
Wrlght-Patterson  AFB,  OH. 

Report 

CTR  F33615-78-C-I502 

Final  rept.  1  Oct  78-31  Jul  81;  NP.  201;  Proj .  2052; 
Task  05;  NTIS  Prices:  PC  A10/MF  AOI;  Monitor 
AFWAL-TR-8 1-1165;  DP.  Sep  81 
The  Digital  Avionics  Informat'on  System  (DAIS) 
represents  a  significant  advance  in  the  technology 
of  avionics  system  architecture.  DAIS  is  a  total 
systems  concept,  exploiting  standardization, 
modularity,  and  application  independent  executive 
software  to  provide  a  system  architecture  adaptable 
to  many  aircraft,  missions,  and  avionics 
configurations  and  fully  capable  of  accommodating 
new  advances  In  technology.  These  fundamental  system 
characteristics  are  described  in  this  report;  the 
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specific  systee  features  ehlch  provide  these 
character  1 st tcs  and  attributes  are  pr#«ented 
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-1-  836783  C.INSPEC 

Tltre  Anglal*  :  THE  IMPACT  OF  ADVANCED  COMPUTER  SYSTEMS  ON  AVIONICS 
RELIABILITY. 

Auteurs  :  BORDEN  A.  G. 

Type  Document  :  Journal  Article 

Tltre  journal  :  DEF.  ELECTRON.  (USA) 

Source  :  VOL. 19,  NO. 5;  PP .  S7-8,  10.  1A,  17-18,  21;  REF.  12; 

DP  MAY  1987 

Coden  :  DEELDH 

Issn  :  0194-7885 

Resume  ;  Integrated  avionics  systems  like  pave  pillar  and 

Icnla  are  among  the  many  beneficiaries  of  advanced 
computer  architectures  and  vhslc  technology. 

_2~  8 19377  C.INSPEC 

Tltre  Anglais  :  MODULAR  ICNIA  PACKAGING  TECHNOLOGY. 

Auteurs  :  PORAOISH  F. 

Affiliation  :  TEXAS  INSTRUMENTS,  MCKINNEY,  TX,  USA 

Type  Document  :  Journal  Article 

Tltre  Journal  :  IEEE  AEROSP.  AND  ELECTRON.  SYST .  MAG.  (USA) 

Source  :  VOL. 2,  NO. 6;  PP.  20-3;  REF.  2;  CCCC- 

0885-8985/87/0600-0020  DOLLARS  01.00;  DP  JUNE  1987 
Coden  :  1ESMEA 

issn  ;  0885-8985 

Resume  ;  The  author  discusses  the  integrated  communication 

navigation  Identification  avionics  program,  which  is 

acnlevlng  significant  size,  weight,  power,  and 
reliability  Improvements  by  the  modular  Integration 
of  similar  functions  Into  a  fault-tolerant 
reconf igurable  architecture.  This  is  being 
accomplished  with  a  combination  of  modular  circuit 
designs  Incorporating  surface-mount  component 
technology,  and  a  modular  two-level  maintenance 
support  concept  for  reduced  life  cycle  cost.  The 
focus  Is  on  the  modular  packaging  technology  of  tne 
digital  processor  subsystem. 

-3-  780666  C.INSPEC 

Tltre  Anglais  ;  THE  APPLICABILITY  OF  THE  EMERGING  AMERICAN  NATIONAL 
STANDARD  FIBER  DISTRIBUTED  DATA  INTERFACE  ( FDDI )  FOR 
A  DISTRIBUTED  AVIONICS  ARCHITECTURE. 

Tltre  Conference:  DIGEST  OF  PAPERS.  COMPCDN  SPRING  '87.  THIRTY-SECOND 
IEEE  COMPUTER  SOCIETY  INTERNATIONAL  CONFERENCE. 
INTELLECTUAL  LEVERAGE  (CAT.  N0.87CH2409-1 ) 

Lieu  Conference  ;  SAN  FRANCISCO,  CA,  USA 
Date  conference  :  23-27  FEB.  1987 
Auteurs  :  COHN  M. 

Type  Document  ;  Conference  Paper 

Edlteur  :  IEEE  COMPUT .  SOC.  PRESS,  WASHINGTON,  DC.  USA 

Source  ;  NP.  XVI+470;  PP.  448*51;  REF.  9;  SPO.  IEEE;  CCCC- 

CH2409- 1/87/0000-044B  DOLLARS  01.00;  DP  1987 
Isbn  :  0-8186-0764-5 

Resume  ;  The  data  coirmunlcat Ion  network  requirements  for  the 

next -generat Ion  distributed  avionics  architecture 
are  analyzed.  The  emerging  amerlcan  national 
standard  fiber  distributed  data  Interface  (fddl) 
local  area  network  (lan)  standard  is  assessed  for 
Its  suitability  In  meeting  those  requirements.  The 
consideration  include:  communications  architecture, 
performance,  and  fault  tolerance. 

-4-  779435  C.INSPEC 

Tltre  Anglais  :  SIMULATION  MODEL  OF  A  HIGH-SPEED  TOKEN-PASSING  BUS 
FOR  AVIONICS  APPLICATIONS. 

Tltre  Conference;  PROCEEDINGS  OF  THE  IEEE/AIAA  7TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  N0.86CH2359-8) 

Lieu  Conference  :  FORT  WORTH,  TX,  USA 

Date  conference  ;  13-16  OCT.  1986 

Auteurs  :  SPIETH  J.  E.;  SEWARD  W.  D. 

Affiliation  :  AERONAUT.  SYST.  DIV. .  WRIGHT-PATTERSON  AIR  FORCE 
BASE.  OH.  USA 

Type  Document  ;  Conference  Paper 

Edlteur  :  IEEE,  NEW  YORK,  USA 

Source  :  NP.  803;  PP .  242-9;  REF.  17;  SPO.  IEEE ; AIAA ;  DP  1986 

Resume  ;  The  design  of  a  protocol  with  performance  that  can 
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meet  the  requirements  for  a  next -generation  aviation 
electronics  (avionics)  data  Dus  Is  considered.  A 
study  tnat  developed  and  validated  a  model  for 
simulating  Dus  token-passing  protocols  for  avionics 
applications  is  reported.  Too  algoritnms  were 
designed  tnat  reflected  the  timing  and  operation  of 
a  dlstriputed  and  a  centralized  control 
token-passing  protocol.  The  algorithms  were 
incorporated  In  an  overall  simulation  model  program 
that  included  control,  data  collection  and  analysis 
functions.  The  simulation  model  program  allows 
various  avionics  Dus  configurations  to  be  defined 
and  tested.  Initial  performance  tests  of  a 
centralized  control  token-passing  protocol  using  a 
configuration  representative  of  a  fighter-type 
aircraft  Dus  network  are  described,  and  the 
performance  of  the  two  types  of  protocols  is 
compared. 

-5-  779420  C.INSPEC 

Tltre  Anglais  :  HELICOPTER  AVIONICS  ARCHITECTURE  FOR  INTEGRATING 
FLIGHT  CRITICAL  FUNCTIONS. 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE/AIAA  7TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  N0.86CH2359-8) 

Lieu  Conference  :  FORT  WORTH .  TX,  USA 
Date  conference  :  13-16  OCT.  1986 
Auteurs  :  OSDER  S.  S. 

Affiliation  :  MCDONNELL  DOUGLAS  HELICOPTER  CO..  TEMPE ,  AZ,  USA 
Type  Document  :  Conference  Paper 
Edlteur  :  IEEE.  NEW  YORK,  USA 

Source  :  NP.  803:  PP.  134-41;  REF.  15:  SPO.  IEEE;AIAA;  CCCC- 

CH2359-8/86/0000-0134  DOLLARS  01.00;  DP  1986 
Resume  :  An  approach  to  the  mechanization  of  the  traditional 

navigation  function  is  described  that  can  provide 
the  key  integration  Interface  between  the 
flight-critical  aircraft  fly-by-wire  staol 1 1 zat ion 
and  control  and  the  remainder  of  the  mission 
avionics.  Redundant,  integrated  navigation  and 
sensor  assemblies  provide  all  of  the  aircraft 
position,  velocity,  acceleration,  angular  rate, 
attitude,  heading,  and  air  data  states  needed  for 
Doth  the  flight  control  as  well  as  the  mission 
management  functions.  The  architecture  concept  uses 
functional  partitioning  with  distributed  processing 
aimed  at  decoupling  software  dependencies  between 
the  various  'Integrated'  avionics  system  elements 

-6-  779414  C.INSPEC 

Tltre  Anglais  :  UNIVERSAL  RECEIVER  FOR  ICNIA. 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE/AIAA  7TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  NO. 86CH2359-8 ) 

Lieu  Conference  :  FORT  WORTH,  TX,  USA 
Date  conference  :  13-16  OCT,  1986 
Auteurs  :  SMEAD  F.  W. 

Affiliation  :  ITT  AVIONICS  DIV. .  NUTLEY,  NJ ,  USA 
Type  Document  :  Conference  Paper 
Edlteur  :  IEEE,  NEW  YORK,  USA 

Source  :  NP.  803;  PP.  85-9;  SPO.  IEEE ;AIAA ;  CCCC- 

CH2359-8/86/0000-0085  DOLLARS  01.00;  DP  1986 
Resume  :  The  architecture  for  the  tenia  (Integrated 

communication  navigation  identification  avionics) 
system,  under  development  for  the  us  military,  is 
highly  modular.  Radio  receive  and  transmit  functions 
are  accomplished  through  real-time 
computer-controlled  Interconnection  of  appropriate 
modules,  whose  parameters  are  also  changed  In  real 
time,  as  required,  for  each  specific  signal  and 
signal  type.  With  such  an  architecture,  the  more 
flexible  each  type  of  module,  the  easier  and  more 
efficient  it  is  to  implement  the  wide  variety  of 
signal  types  which  the  Icnla  system  must  process  and 
to  new  signal  types  In  the  future.  The  design  of 
such  a  receiver  is  described. 
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Tltre  Anglais  :  FAULT-FREE  PERFORMANCE  VALIDATION  OF  AVIONIC 
MULTIPROCESSORS. 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE/AIAA  7TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  N0.86CH2359-8) 

Lieu  Conference  :  FORT  NORTH,  TX,  USA 
Date  conference  :  13-16  OCT.  1966 

Auteurs  :  CZECK  E.  W. ;  FEATHER  F.  E.;  GRIZZAFFI  A.  M. ;  FINELLI 

G.  6. ;  SEGALL  Z.  Z. ; 

Affiliation  :  CARNEGIE  MELLON  UNIV.,  PITTSBURGH,  PA.  USA  (03): 

Type  Document  :  Conference  Paper 

Edlteur  :  IEEE,  NEW  YORK,  USA 

Source  :  NP.  803;  PP.  670-7;  REF.  10;  SPO.  1EEE.AIAA;  CCCC« 

CH2359-8/86/0000-0670  DOLLARS  01.00;  DP  1986 
Resume  ;  The  application  of  a  validation  methodology  to 

nasa's  fault-tolerant  multiprocessor  system  and  the 
software  Implemented  fault-tolerance  computer  system 
Is  described.  The  methodology  entails  a  building 
block  approach,  starting  Kith  simple  baseline 
experiments  and  building  to  more  complex 
experiments.  The  goal  methodology  Is  to  test  and 
characterize  thoroughly  the  performance  and  behavior 
of  uitrarel table  computer  systems.  The  results  snow 
that  the  methodology  Is  not  machine-specific  and  can 
be  used  in  lieu  of  life-testing  approaches.  By 
applying  a  building-block  approach  at  the  systems 
level,  the  machine  complexity  was  broken  down  to 
manageable  levels  independent  of  system 
implementat ion. 

-8-  766641  C.INSPEC 

Tltre  Anglais  :  CHANNELIZED  OR  NONCHANNELIZED  FAULT-TOLERANT 

COMPUTERS:  A  HARDWARE  COMPLEXITY  COMPARISON  OF 
FAULT-TOLERANT  COMPUTERS  FOR  FLIGHT  CONTROL  SYSTEMS. 
Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE/AIAA  7TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  NO. B6CH2359-B ) 

Lieu  Conference  :  FORT  WORTH,  Tx.  USA 

Date  conference  :  13-16  OCT.  1986 

Auteurs  :  SCHMID  H.  ;  LARIMER  S.  ;  MADAK  T. 

Affiliation  :  GENERAL  ELECTRIC  CO..  BINGHAMTON,  NY.  USA  (03); 

Type  Document  ;  Conference  Paper 

Edlteur  ;  IEEE.  NEW  YORK,  USA 

Source  :  NP .  803;  PP.  655-63;  REF.  8;  SPO.  IEEE ; AIAA ;  CCCC* 

CH2359-8/86/OOOO-0655  OOLLARS  01.00;  DP  1986 
Resume  :  F 1 Ight -cr 1 t leal  control  systems  for  future  aircraft, 

such  as  the  advanced  tactical  fighter  (atf),  demand 
higher  reliability,  greater  fault  tolerance,  and 
more  computing  power  as  well  as  easier  maintenance 
and  reduced  life  cycle  costs.  The  conventional 
approach  to  implementing  these  systems  has  been  to 
use  channelized  architectures.  Nonchannel  1  zed 
reconf Igurable  mu l t 1 processor  systems  (rmpss),  which 
have  been  In  development  for  the  last  decade,  are 
said  to  provide  greater  hardware  efficiency  and 
lower  recurring  costs  at  the  price  of  higher 
software  and  system  complexity,  and  more  difficult 
validation  and  verification  processes.  The  hardware 
complexity  of  the  rmps  Is  evaluated  by  comparing 
gate  and  pin  counts  of  four  fault-tolerant  computer 
architectures.  The  reliability  results  are 
presented. 

-9-  766634  C.INSPEC 

Tltre  Anglais  :  A  FAULT  TOLERANT  PROCESSOR  TO  MEET  RIGOROUS  FAILURE 
REQUIREMENTS  yAIRBORNE  APPLICATIONS  1 . 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE/AIAA  7TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  NO . 86CH2359-8 ) 

Lieu  Conference  :  FORT  WORTH,  Tx,  USA 
Date  conference  .-  13-16  OCT.  1986 

Auteurs  ;  LALA  J.  H. ;  ALGER  L.  S. ;  GAUTHIER  R.  J.;  DZWONCZYK 

M.  J. 

Affiliation  :  CHARLES  STARK  DRAPER  LAB.  INC.,  CAMBRIDGE,  MA.  USA 
(04); 

Type  Oocument  :  Conference  Paper 

Edlteur  :  IEEE,  NEW  YORK,  USA 
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Auteurs 

Af f 1 i iat ion 

Type  Document 

Tltre  Journal 

Source 

Coden 

Issn 

Resume 


:  NP.  803;  PP.  555-62;  REF.  8;  SPO.  IEEE;AIAA;  CCCC- 
CH2359-8/86/0000-0555  DOLLARS  01.00;  DP  1986 
;  There  Is  a  need  for  extremely-hlgh-rel laDI 1 Ity 
airborne  computers  for  applications  in  advanced 
military  and  civilian  aircraft  to  carry  out  such 
traditional  functions  as  guidance,  navigation,  and 
flight  control  as  well  as  tasks  associated  with  more 
advanced  functions  such  as  an  electronic  pilot's 
associate  and  an  electronic  flight  engineer.  A 
fault-tolerant  computer  architecture  has  been 
designed  In  conformance  with  rigorous  theory  for 
such  hlgh-rel labl 1 ity  applications  to  tolerate  any 
arbitrary  failure  mode  of  hardware  components.  The 
computer  architecture,  Its  hardware  implementation, 
the  operating  system  and  the  redundancy  management 
software  and  Its  interfaces  to  external  devices  are 
described. 

INSPEC 

:  SOME  VERIFICATION  TOOLS  AND  METHODS  FOR  AIRBORNE 
SAFETY-CRITICAL  SOFTWARE. 

:  HELPS  K .  A. 

:  SMITHS  IND.  AEROSPACE  AND  DEFENCE  SYST .  LTD., 
CHELTENHAM,  ENGLAND 
;  Journal  Article 
:  SOFTWARE  ENG.  J.  (GB) 

;  VOL. 1 ,  NO. 6;  PP .  248-53;  REF.  6;  DP  NOV.  1986 
;  SEJOED 
:  0268-6961 

:  Airborne  software,  like  many  other  kinds  of  embedded 
software,  grows  In  complexity  with  each  generation 
of  equipment.  Where  the  software  supports 
safety-critical  functions  this  can  present  severe 
verification  problems.  The  scale  of  such  software  Is 
often  outside  the  scope  of  mathematically  formal 
verification,  and  dissimilar  software  redundancy 
techniques  may  be  inapplicable  for  performance 
reasons.  A  practical  approach  is  to  meet 
safety-critical  criteria  by  procedural ly  formal 
verification  in  line  with  the  radio  technical 
commission  for  aeronautics  and  the  european 
organisation  for  civil  aviation  electronics  common 
revised  (1985)  guidelines  on  the  software  aspects  of 
certification  of  airborne  systems,  using  a 
comprehensive  automated  test  coverage  analysis  and 
partition  breach  analysis  system. 

INSPEC 

:  THE  EXPERIMENTAL  AIRCRAFT  PROGRAMME  SOFTWARE 
TOOLSET . 

;  CRONSHAW  P. 

:  BAE  PLC. .  PRESTON,  ENGLAND 
;  Journal  Article 
:  SOFTWARE  ENG.  J.  (GB) 

:  VOL . 1 ,  NO. 6;  PP .  236-47;  REF.  11;  DP  NOV.  1986 
;  SEJOED 
:  0268-6961 

:  The  experimental  aircraft  programme  (eap)  is  a 
technology  demonstrator  project  in  advance  of  the 
next  generation  of  fighter  aircraft.  An  Integrated 
software  toolset  has  been  established  to  support  the 
development  and  production  of  software  for  the 
advanced  avionic  systems  embedded  In  this  aircraft. 
This  paper  presents  the  work  undertaken  and  the 
experience  gained  In  developing,  using  and 
supporting  the  eap  software  toolset  from  project 
Initiation  to  final  delivery  of  the  software  for 
flight  testing.  Many  of  the  Issues  pertaining  to  the 
future  requirements  of  an  integrated  project  support 
environment  and  the  rigours  Imposed  In  delivering 
reliable  and  high-quality  real-time  software  for 
embedded  processors  are  discussed. 
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Tltre  Conference: 

Lieu  Conference 
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Auteurs 
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Resume 


MULTIOBJECTIVE  INSENSITIVE  COMPUTER-AIDED  DESIGN  OF 
AEROSPACE  CONTROL  SYSTEMS. 

CONTROL  APPLICATIONS  OF  NONLINEAR  PROGRAMMING  AND 

optimization,  proceedings  of  the  fifth  ifac  workshop 

CAPRI.  ITALY 
11-14  JUNE  1985 

SCHY  A.  A.;  GIESY  D.  P.;  DI  PILLO  G. 

NASA  LANGLEY  RES.  CENTER.  HAMPTON,  VA.  USA 
Conference  Paper 
PERGAMON.  OXFORD,  ENGLAND 

NP.  X+209 ;  PP.  177-88:  REF,  15;  SPO.  IFAC;UNIV.  ROME 
'LA  SAPIENZA' :UNIV.  CALABR!A;ET  AL;  DP  1986 
A  multlobjectlve  cad  metnod  for  aircraft  control 
systems  nas  been  developed  which  can  meet 
requirements  on  disparate  objectives  over  a  set  of 
flight  conditions,  using  constrained  minimization 
algorithms  with  objective  functions  In  the 
constraint  vector.  This  paper  summarizes  results  of 
research  on  four  increasingly  sophist icated  versions 
of  the  method:  the  basic  method;  an  extension  which 
finds  pareto  optimal  designs  which  are  well-balanced 
In  all  objectives;  an  extension  which  finds 
stochastic-insensitive  (si)  designs  to  minimize  the 
sensitivity  to  uncertain  parameters;  and  a  tradeoff 
method  which  designs  for  a  compromise  between 
decreased  sensitivity  and  Improved  nominal  objective 
values. 
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.  INSPEC 

:  COMMON  SIGNAL  PROCESSOR  DESIGNED  FOR  MULTIPLE 
APPLICATIONS. 

:  LEE  W.  H.;  DENNIS  C.  A.;  GILBERT  W.  L. 

:  DIV.  OF  FEDERAL  SYST.,  IBM,  MANASSAS.  VA.  USA  (03); 

;  Journal  Article 

:  DEF.  ELECTRON.  (USA) 

:  VOL. 18,  NO. 7;  PP .  176*179;  DP  JULY  19B6 

:  DEELDH 

:  0194-7885 

:  Future  military  electronic  systems  will  Incorporate 
more  and  more  very  large-scale  integration  (vlsl). 
and  ibm's  federal  systems  division  (fsd)  is  a  major 
participant  In  developing  the  necessary 
technological  groundwork.  One  of  the  first  fruits  of 
this  development  effort,  a  military  signal  processor 
relying  almost  exclusively  on  vlsl  component 
technology,  is  being  developed  by  fsd  for  the  air 
force's  pave  pillar  Integrated  avionics  program. 
Called  the  common  signal  processor  (csp).  It  will 
feature  an  architecture  flexible  enough  to  follow 
for  a  variety  of  applications  and  for  future  growth. 
The  csp  features  advanced  complementary  metal-oxide 
semiconductor  (cmos)  circuitry  with  resolution  of 
Individual  elements  down  to  the  1-mlcron  level. 
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TEXAS  INSTRUMENTS  VHSIC  1750A  COMPUTER. 

PROCEEDINGS  OF  THE  IEEE  1986  NATIONAL  AEROSPACE  AND 
ELECTRONICS  CONFERENCE,  NAECON  1986  (CAT. 

NO .  86CH2307-7 ) 

DAYTON,  OH,  USA 
19-23  MAY  1986 
NORMAN  L  E 

TEXAS  INSTRUM.  INC..  DALLAS,  TX.  USA 
Conference  Paper 
IEEE,  NEW  YORK,  USA 

NP.  4  VOL.  1399;  PP.  125-30  VOL.l;  REF.  4;  SPO. 
IEEE;  CCCC-  0547-3578/86/0000-0125*01.00;  DP  1986 
Future  tactical  aircraft  and  vehicles  will  carry 
several  different  sensors  including  advanced  fllrs, 
radars,  ew,  and  (in  some  cases)  acoustic  systems. 
The  sensor  outputs  will  need  to  be  integrated  and 
displayed  to  the  operator  in  a  condensed  and 
prioritized  manner.  To  fulfil  this  requirement,  a 
new  generation  of  programmable  ml 1-std-1750a 
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architecture  hardware  Is  needed  to  produce 
state-of-the-art  processors  with  high  throughput  and 
99percent  fault  coverage  at  the  nodule  level,  a 
description  is  given  of  new  vhslc  Ics  being  used  in 
the  design  of  a  1750a  architecture  computer  during 
1986.  The  vhslc  1750a  computer  will  provide  high 
processing  throughput,  system  reconfigurability,  and 
two-level  maintenance,  and  will  lower  system  power 
requirements  at  significant  hardware  savings. 

-15-  620646  C.INSPEC 

Tltre  Anglais  :  CAPABILITY  ASSESSMENT  IN  AIRBORNE  PLATFORMS. 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE  1986  NATIONAL  AEROSPACE  AND 
ELECTRONICS  CONFERENCE,  NAECON  1986  (CAT. 
N0.86CH2307-7) 

Lieu  Conference  :  DAYTON,  OH.  USA 
Date  conference  :  19-23  MAY  1986 
Auteurs  :  ELENGICAL  G. ;  LUNDE  D. 

Affiliation  :  WESTINGMOUSE  ELECTR.  CORP . .  BALTIMORE.  MD,  USA  (02); 
Type  Document  :  Conference  Paper 

Edlteur  :  IEEE,  NEW  YORK,  USA 

Source  :  NP.  4  VOL.  1399;  PP .  119-24  V0L.1;  SPO.  IEEE;  CCCC- 

0547-3578/86/0000-01 19S01 .00;  DP  1986 
Resume  :  The  multimode  weapons  systems  of  the  future  will  be 

highly  fault-tolerant,  possessing  the  ability  to 
perform  tactical  missions  with  both  full  or  degraded 
functional  capabilities.  The  fault-tolerant  system 
characteristics  will  allow  systems  with  less  than 
tne  fully  specified  functional  capabilities  to  be 
engaging  In  combat.  This  design  feature  will  present 
the  operators  of  these  weapons  systems  with  the 
operational  challenge  of  selecting  and/or  assigning 
weapons  platforms  wltn  degraded  capabilities  to 
carryout  tactical  missions.  An  'in-system' 
assessment  process  Is  proposed  to  evaluate  the 
operability  for  these  weapons  platforms  based  on  the 
current  functional  status,  the  reliability  of  the 
hardware  resources  within  the  system's  avionics,  and 
the  resources  required  by  the  various  application 
modes  to  accomplish  mission  tasKs. 

-16-  612197  C.INSPEC 

Tltre  Anglais  :  AF  MULTIPROCESSOR  FLIGHT  CONTROL  ARCHITECTURE 
DEVELOPMENTS:  CRMMFCS  AND  BEYOND. 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE  1986  NATIONAL  AEROSPACE  AND 
ELECTRONICS  CONFERENCE,  NAECON  1986  (CAT. 
N0.86CH2307-7) 

Lieu  Conference  :  DAYTON.  OH,  USA 

Date  conference  :  19-23  MAY  1986 

Auteurs  :  THOMPSON  0.  8.;  BORTNER  R.  A. 

Affiliation  :  US  AIR  FORCE  WRIGHT  AERONAUT.  LABS.. 

WRIGHT-PATTERSON  AIR  FORCE  BASE.  OH,  USA  (02); 

Type  Document  :  Conference  Paper 

Edlteur  :  IEEE,  NEW  YORK,  USA 

source  :  NP.  4  VOL.  1399;  PP .  376-82  VOL. 2;  REF.  14;  SPO. 

IEEE;  DP  1986 

Resume  :  Since  1978,  the  air  force  wrlght  aeronautical 

laboratories  flight  dynamics  laboratory  has  been 
Involved  in  In-house  research  Into  fault-tolerant 
multiprocessor  flight  control  systems.  The  emphasis 
of  these  studies  has  been  on  applying  microprocessor 
technology,  dynamic  sparing,  and  distributed 
parallel  processing  techniques  rather  than 
conventional  triple  or  quadruple  channel  computer 
structures.  The  pertinent  issues,  systems,  and 
concepts  leading  to  the  current  work  on  the  advanced 
multiprocessor  control  architecture  definition 
(amcad)  program  are  discussed. 

-17-  612196  C.INSPEC 

Tltre  Anglais  :  ADVANCED  INFORMATION  PROCESSING  SYSTEM:  STATUS 
REPORT . 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE  1986  NATIONAL  AEROSPACE  AND 
ELECTRONICS  CONFERENCE,  NAECON  1986  (CAT. 

NO. 86CH2307-7 ) 
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Lieu  Conference  :  DAYTON.  OH,  USA 
Date  conference  :  19-23  MAY  1986 
Auteurs  :  BROCK  L.  D.;  LALA  J. 

Affiliation  :  CHARLES  STARK  DRAPER  LAB.  INC..  CAMBRIDGE.  MA,  USA 
(02); 

Type  Oocument  ;  Conference  Paper 

EOHeur  :  IEEE.  NEW  YORK,  USA 

Source  :  NP.  4  VOL.  1399;  PP.  368-75  VOL. 2;  REF.  2;  SPO. 

IEEE;  CCCC-  0547-3578/86/0000-0368S01 .00;  DP  1986 
Resume  :  The  advanced  Information  processing  system  (alps)  Is 

designed  to  provide  a  fault-tolerant  and 
damage-tolerant  data  processing  architecture  for  a 
broad  range  of  aerospace  vehicles.  The  alps 
architecture  also  has  attributes  that  enhance  system 
ef feet Ivertess,  such  as  graceful  degradation,  growth 
and  change  tolerance,  and  Integrabl 1 1 1 y .  Two  key 
building  blocks  being  developed  for  the  alps  program 
are  a  fault-ano-damage  tolerant  processor  and 
communication  network.  A  proof-of-concept  system  is 
now  being  built  and  will  be  tested  to  demonstrate 
the  validity  and  performance  of  the  alps  concepts. 

-18-  597848  C.INSPEC 

Tltre  Anglais  ;  POSSIBLE  IMPACT  OF  VHSIC  ON  MIL-STD- 1553B  DATA 
TRANSMISSION  MANAGEMENT. 

Tltre  Conference;  IMPACT  OF  VERY  HIGH  PERFORMANCE  INTEGRATED  CIRCUITS 
ON  RADAR,  GUIDANCE  AND  AVIONICS  SYSTEMS.  AVIONICS 
PANEL  49TH  SYMPOSIUM  (AGARD-CP-380) 

Lieu  Conference  ;  LISBON,  PORTUGAL 

Date  conference  :  20-25  MAY  1985 

Auteurs  ;  BERARDI  L.;  MERLANO  M. 

Affiliation  ;  GRUPPO  SISTEMI  AVIONICI  ED  EOUIPAGGIAMENTI , 

AERITALIA ,  TORINO,  ITALY  (02); 

Type  Document  ;  Conference  Paper 

Edlteur  :  AGARD,  NEUILLY-SUR-SEINE,  FRANCE 

Source  ;  NP.  XVI+382;  9 P.  36/1-12;  REF.  1;  SPO.  NATO;  DP  OCT. 

1985 

Resume  :  High  performance  Integrated  circuit  technologies 

allow  for  dramatic  Improvement  in  speed  and 
reduction  In  size  of  the  Integrated  circuits.  This 
fact  results  In  the  possibility  to  pack  in  a  denser 
way  the  computing  and  decision-making  functions  of 
the  avionics  systems.  Nevertheless  it  Is  still 
necessary  to  connect  together  the  various  system 
components,  spread  through  the  airframe,  by  means  of 
an  tnterfunct Ion  data  transmission  system.  For  these 
reasons  the  application  of  the  new  technologies  to  a 
mi  1 -std-l553b  data  transmission  system  is 
considered.  In  particular  the  data  management  task 
allocated  to  the  bus  controller  Is  described  in  four 
Increasing  levels  of  complexity,  ranging  from  the 
minimum  requirement  to  an  'expert'  function 
including  an  high  degree  of  configurability.  The 
performance  obtainable  by  Implementing  the  functions 
In  the  current  or  new  technologies,  and  with  two 
different  architectural  solutions,  are  measured  or 
estimated.  The  comparison  among  the  obtained  results 
shows  that  the  new  technologies  not  only  Improve  the 
performances  of  the  data  transmission  system  but 
also  allow  to  include  an  higher  degree  of 
Intelligence  In  the  function,  extending  in  this  way 
the  application  of  ml !-std-1553b  to  future  advanced 
avionic  systems. 

-19-  597847  C.INSPEC 

Tltre  Anglais  :  THE  IMPACT  OF  VERY  HIGH  PERFORMANCE  INTEGRATED 
CIRCUITS  ON  AVIONICS  SYSTEM  READINESS. 

Tltre  Conference:  IMPACT  OF  VERY  HIGH  PERFORMANCE  INTEGRATED  CIRCUITS 
ON  RAOAR ,  GUIDANCE  AND  AVIONICS  SYSTEMS.  AVIONICS 
PANEL  49TH  SYMPOSIUM  (AGARD-CP-380) 

Lieu  Conference  :  LISBON,  PORTUGAL 
Date  conference  :  20-25  MAY  1985 
Auteurs  :  STRULL  G. 

Affiliation  :  DIV.  OF  AOV.  TECHNOL. ,  WESTINGHOUSE  ELECTR.  CORP. , 
BALTIMORE,  MD,  USA 
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Conference  Paper 

AGARD,  NEUILLY-SUR-SEINE,  FRANCE 
NP.  XVI+382;  PP.  35/1-4;  SPO.  NATO;  DP  OCT.  1985 
Vhplc  represents  a  new  systems/tecnnology  culture. 
Wltn  a  philosophy  of  top-down  design  and  bottom-up 
build,  a  vehicle  Is  provided  to  avoid  rapid  device 
obsolescence  so  prevalent  In  the  fast  moving 
integrated  circuit  Industry.  However,  to 
successfully  and  effectively  design  advanced  systems 
In  this  manner,  a  design  methodology  Is  required 
that  adequately  addresses  the  challenge  shown.  Since 
everything  from  chip  definition  through  application 
analysis  Is  Interactive  with  everything  else,  the 
challenge  Is  to  adequately  Keep  track  of  all  the 
perimeters  and  their  relationship.  The  methodology 
by  which  design  and  analysis  are  accomplished  is 
shown.  The  starting  point  Is  the  systems 
architecture  and  its  application  software.  From  the 
architecture  and  application  software  the 
partitioning  of  the  system  Into  appropriate  modules 
can  be  derived.  From  this  an  idea  of  the  integrated 
circuits  needed  can  be  determined.  This  Is  the  way 
the  design  proceeded  on  'day  one'  of  this  technology 
revolution.  However,  at  this  point  In  time  the 
author  has  a  library  of  mlnlcells  and  logic  for 
creating  macros  so  that  he  Is  well  along  In  the  chip 
development  area.  Therefore,  he  has  the  basis  for 
simulation  anq  the  design  continues  in  an 
Interactive  manner. 

-20-  559521  C  INSPEC 

Tltre  Anglais  :  AVIONICS,  SOFTWARE.  AND  AUTOMATION. 

Tltre  Conference:  IEEE  EASCON'95  >8TH  ANNUAL  ELECTRONICS  AND 

AEROSPACE  SYSTEMS  CONFERENCE  (CAT.  NO. 85CH22 13-7 ) 
Lieu  Conference  ;  WASHINGTON.  DC,  USA 
Date  conference  :  28-30  OCT.  1985 

Auteurs  :  HARRISON  J.  V.  A.;  LALA  J.  H.;  BROCK  L.  D. 

Affiliation  ;  CHARLES  STARK  DRAPER  LAB.  INC..  CAMBRIDGE.  MA ,  USA 
(03); 

Type  Document  :  Conference  Paper 

Edlteur  :  IEEE,  NEW  YORK,  USA 

Source  :  NP.  378;  PP .  93-109;  SPO.  IEEE;  CCCC- 

CH2213-7/85/0000-0093S01 .00;  DP  1985 
Resume  ;  Summary  form  only  given.  The  avionics  functions  In  a 

launch  vehicle  or  an  orbital  transfer  vehicle  are 
interpreted  In  a  very  proad  context.  They  include 
all  applications  of  electronics  technology  to 
signal,  data,  and  symbolic  processing,  all  of  the 
Information  processing  functions  Such  as  guidance, 
navigation,  and  control,  propulsion  control, 
decision  support  functions  such  as  information 
fusion  and  planning,  and  Displays,  controls,  and 
other  man-machine  interfaces.  In  the  area  of 
software,  numerous  opportunities  exist  to  upgrade 
the  present  state  of  the  art.  Software  complexity 
can  be  reduced  by  the  development  of  very-high-level 
languages  and  other  supporting  tools  such  as 
automatic  code  generators.  Software  reliability,  can 
be  Improved  through  the  development  of 
fault-tolerant  technologies.  Automation  represents  a 
significant  new  opportunity  to  enhance  system 
performance  while,  at  the  same  time,  containing 
system  life-cycle  costs. 

-21-  515953  C. INSPEC 

litre  Anglais  :  TOWARD  AN  AVIONICS  SUPERSYSTEM. 

Type  Document  :  Journal  Article 
Tltre  Journal  :  DEF .  ELECTRON.  (USA) 

Source  :  VOL. 17,  NO. 12;  PP.  73-85;  DP  DEC.  1985 

Coden  :  DEELDH 

Issn  :  0194-7885 

Resume  :  The  long-term  goal  Is  to  create  a  slngte,  modular 

avionics  system  for  communication,  navigation, 
targeting,  fire  control,  offensive  and  defensive  ew, 
monitoring  of  systems  status,  and  other  functions, 
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all  control  lea  Dy  a  central  computer  ana  connectea 
by  a  multiplex  Dus.  One  of  the  leading  efforts  In 
this  field  is  the  air  force's  pave  pillar  program, 
which  is  Intended  to  create  the  architecture  for 
such  a  system;  Its  results  will  be  Integrated  into 
army  and  navy  avionics  programs.  Pave  pillar  has  not 
yet  reached  the  hardware  stage;  It  has,  however, 
produced  some  definite  concepts  for  a  fully 
integrated  avionics  system. 

-22-  483169  C.INSPEC 

Tit re  Anglais  :  FAULT  TOLERANT  HARDWARE/SOFTWARE  ARCHITECTURE  FOR 
FLIGHT  CRITICAL  FUNCTION  ( AGARD-LS- 143 ) . 

Tltre  Conference:  FAULT  TOLERANT  HARDWARE /SOFTWARE  ARCHITECTURE  FOR 
FLIGHT  CRITICAL  FUNCTION  ( AGARD-LS- 143 ) 

Lieu  Conference  :  EDWARDS,  USA 

Date  conference  :  1-2  OCT.  1985 

Type  Document  :  Conference  Proceedings 

Edlteur  :  AGARD,  NEUILLY-SUR-SEINE,  FRANCE 

Source  :  NP.  IV* 146 ;  SPO.  AGARD;  DP  1985 

Resume  ;  The  following  topics  were  dealt  with;  digital 

fly-by-wire  experience;  redundancy  management  of 
synchronous  and  asynchronous  systems;  software  fault 
tolerance  experiments;  dependable  avionic  data 
transmission;  multicomputer  fault-tolerant  systems 
using  ada;  design  Issues  In  data  synchronous 
systems;  digital  fault-tolerant  flight  actuation 
systems;  and  design  validation  of  fly-by-wire  flight 
control  systems.  Abstracts  of  Individual  papers  can 
be  found  under  the  relevant  classification  codes  in 
this  or  other  issues. 

-23-  461976  C.INSPEC 

Tltre  Anglais  :  GENERAL  DYNAMICS  CONVAIR  DIVISION  TOTALLY 
RECONF I GURABLE  EMBEDDED  COMPUTER. 

Tltre  Conference:  PROCEEDINGS  OF  THE  AIAA/IEEE  6TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  NO.  84CH-2132-9) 

Lieu  Conference  :  BALTIMORE,  MD,  USA 

Date  conference  :  3-6  OEC.  1984 

Auteurs  :  MARKERT  L.;  HEDTKE  P.;  KUSEK  J. 

Affiliation  :  GEN.  DYNAMICS  CORP. .  SAN  DIEGO,  CA.  USA  (03); 

Type  Document  :  Conference  Paper 
Edlteur  :  AIAA ,  NEW  YORK,  USA 

Source  :  NP.  XXXV+666;  PP .  646-52;  REF.  4;  SPO.  IEEE;  AIAA; 

DP  1985 

Resume  ;  Modern  avionics  platforms  require  data  processing 

systems  that  are  extensible,  maintainable,  and 
affordable.  A  general-purpose  embedded  computer 
system  Is  being  developed  for  cruise  missile  and 
launch  vehicle  avionics  applications.  Major 
development  objectives  Include  implementation  of  us 
dept.  Of  defense  embedded  computer  standards,  a 
functionally  flexible  and  modular  design,  and  a 
producible  system  that  Is  maintainable,  reliable, 
and  cost-effective.  The  hardware  elements  are 
described  along  with  the  details  of  their  functional 
Interfaces  and  the  overall  system  architecture.  An 
integration  and  maintenance  support  system  is 
described.  Software  support  and  the  implementation 
philosophy  are  also  discussed. 

-24-  461975  C.INSPEC 

Tltre  Anglais  :  MODULAR  AVIONICS  PACKAGING  STANDARDIZATION. 

Tltre  Conference:  PROCEEDINGS  OF  THE  AIAA/IEEE  6TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  NO.  84CH-2132-9) 

Lieu  Conference  :  BALTIMORE,  MD,  USA 

Date  conference  ;  3-6  DEC.  1984 

Auteurs  :  AUSTIN  M. ;  MCNICHOLS  J.  K. 

Type  Document  :  Conference  Paper 

Edlteur  :  AIAA,  NEW  YORK,  USA 

Source  :  NP.  XXXV+666;  PP.  641-5;  SPO.  IEEE;  AIAA;  DP  1985 

Resume  ;  Advanced  Integration  technologies  such  as  high  speed 

data  busing,  bul l t-ln-test  (bit),  very  large  scale 
integration  (vlsl)  and  very  high  speed  Integrated 
circuits  (vhslc)  provide  an  opportunity  to  further 
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Integrate  military  avionics  systems.  It  Is  pointed 
out,  however,  that  these  new  technologies  can  Oe 
severely  limited  If  placed  In  conventional  avionics 
system  architectures.  To  fully  utilize  the  benefits 
of  these  technologies,  modular  packaging 
standardization  across  multiple  functions,  multiple 
systems,  and  multiple  airframes  Is  needed.  It  is 
stressed  that  new  methods  of  packaging  this  new 
generation  of  avionics  are  necessary  to  capitalize 
on  benefits  such  as  common  sources,  improved 
maintainability.  Increased  reliability,  and  reduced 
1 Ife  cycle  costs. 

-25-  461963  C.INSPEC 

Tltre  Anglais  :  VLSI  CHIP  SET  FOR  HIGH-PERFORMANCE  AVIONIC 
COMPUTERS. 

Tltre  Conference:  PROCEEDINGS  OF  THE  AIAA/IEEE  6TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  NO.  84CH-2132-9) 

Lieu  Conference  :  BALTIMORE,  MD,  USA 

Date  conference  :  3-6  DEC-  1984 

Auteurs  :  FORDE  S.  J.;  HILMANTEL  M.  A. 

Affiliation  :  SANDERS  ASSOCIATES  INC.,  NASHUA,  NH,  USA  (02); 

Type  Document  :  Conference  Paper 

Edlteur  :  AIAA,  NEW  YORK,  USA 

source  :  NP.  XXXV+666 ;  PP.  569-72;  REF.  1;  SPO.  IEEE;  AIAA; 

DP  1985 

Resume  :  Advanced  cmos  processing  with  line  widths  of  two 

micrometers  makes  possible  a  vlsl  implementation  of 
avionics  computers.  Using  a  chip  set  designed  with 
6000-gate  gate  arrays  has  led  to  the  design  of  a 
very  high-performance,  yet  small,  low-power, 
cost-effective,  and  highly  flexible  avionics 
computer.  The  chip  set  comprises  four  chips:  the 
microsequencer,  the  arithmetic  and  logic  unit,  the 
operand  generator  unit,  and  the  memory  controller 
unit.  The  four  chips  can  be  configured  to  Implement 
the  us  air  force  standard  instruction  set 
architecture  (ml 1-std-l750a,  notice  l)  and  emulate 
the  us  navy  standard  computers  (an/uyk-20, 
an/ayk-14,  and  an/uyk-44).  An  overview  of  the  chip 
architectures  Is  presented. 

-26-  461938  C.INSPEC 

Tltre  Anglais  :  INTEGRATED  AVIONICS  FOR  ADVANCED  ARMY  ROTORCRAFT . 
Tltre  Conference:  PROCEEDINGS  OF  THE  AIAA/IEEE  6TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  NO.  84CH-2132-9) 

Lieu  Conference  :  BALTIMORE,  MD,  USA 
Date  conference  :  3-6  DEC.  1984 

Auteurs  :  EVERSOLE  W.  L. ;  KICZUK  W.  F.:  LAMBRECHT  J.  A.; 

RIVARD  R.  L. ;  WILLIAMS  J.  J . ; 

Affiliation  :  TEXAS  INSTRUM.  INC.,  DALLAS,  TX,  USA  (06); 

Type  Document  :  Conference  Paper 

Edlteur  :  AIAA,  NEW  YORK,  USA 

Source  :  NP.  XXXV+666;  PP.  352-8;  SPO.  IEEE;  AIAA;  DP  1985 

Resume  :  An  approach  to  the  development  of  an  advanced 

avionics  architecture  to  meet  the  functional 
requirements  of  the  us  army's  next  generation  of 
rotorcraft  (Ihx)  Is  presented.  Mission  requirements 
are  Drlefly  discussed  to  Identify  the  functional 
partitioning  of  the  Ihx  system.  This  Is  followed  by 
a  brief  overview  of  each  subsystem.  The  requirements 
of  the  processing  algorithms  are  discussed  to 
quantitatively  Identify  the  performance  requirements 
of  the  avionics  architecture.  Also  described  is  a 
multiprocessor,  multisensor  architecture  Involving 
high  bandwidth  sensors,  low  bandwidth  sensors,  and  a 
hierarchy  or  processing  structures  and 
Interconnections  that  provides  the  flexibility, 
reliability,  availability,  and  fault  tolerance 
within  the  power,  volume,  and  weight  constraints 
imposed  by  ihx. 

-27-  461925  C.INSPEC 

Tltre  Anglais  :  TEST  EXPERIENCE  ON  AN  ULTRARELIABLE  COMPUTER 
COMMUNICATION  NETWORK  *F LIGHT  CONTROL  SYSTEM 
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APPLICATION! . 

Tltre  Conference:  PROCEEDINGS  OF  THE  AIAA/IEEE  6TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  NO.  84CH-2132-9) 

Lieu  Conference  :  BALTIMORE,  MD,  USA 
Date  conference  :  3-6  DEC.  1984 
Auteur*  :  ABBOTT  L.  W. 

Affiliation  :  AMES  RES.  CENTER.  NASA,  EDWARDS.  CA,  USA 
Type  Document  :  Conference  Paper 
Edlteur  :  AIAA.  NEW  YORK.  USA 

Source  :  NP.  XXXV+666 ;  PP.  233-8;  REF.  6;  SPO.  IEEE;  AIAA;  DP 

1985 

Resume  :  The  dispersed  sensor  processing  mesh  (dspm)  Is  an 

experimental,  ultrarel lable,  fault-tolerant  computer 
communications  network  that  exhibits  an  organic-! Ike 
ability  to  regenerate  Itself  after  suffering  damage. 
The  regeneration  is  accomplished  by  two 
rout  1 nes-grow  and  repair.  The  author  discusses  the 
dspm  concept  for  achieving  fault  tolerance  and 
provides  a  brief  description  of  the  mechanization  of 
both  the  experiment  and  the  six-node  experimental 
network.  The  main  topic  Is  the  system  performance  of 
the  growth  algorithm  contained  In  the  growth 
routing.  The  characteristics  Imbued  to  dspm  by  the 
growth  algorithm  are  also  discussed.  Data  from  an 
experimental  dspm  network  and  software  simulation  of 
larger  dspm-type  networks  are  used  to  examine  the 
Inherent  limitation  on  growth  time  Dy  the  growth 
algorithm  and  the  relationship  of  growth  time  to 
network  size  and  topology. 

-28-  451118  C. INSPEC 

Tltre  Anglais  •  USING  ADA  FOR  A  DISTRIBUTED.  FAULT  TOLERANT  SYSTEM 
yAVIONICS  APPLICATIONS!. 

Tltre  Conference:  PROCEEDINGS  OF  THE  AIAA/IEEE  6TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  NO.  84CH-2132-9) 

Lieu  Conference  :  BALTIMORE,  MD.  USA 

Date  conference  :  3-6  DEC.  1984 

Auteurs  :  DEWOLF  J.  B. ;  SODANO  N.  M. ;  WHITTREDGE  R.  S. 

Affiliation  :  CHARLES  STARK  DRAPER  LAB..  INC.,  CAMBRIDGE,  MA.  USA 

(03); 

Type  Document  :  Conference  Paper 

Edlteur  :  AIAA,  NEW  YORK,  USA 

Source  :  NP.  XXXV+666;  PP.  477-84;  REF.  6;  SPO.  IEEE;  AIAA; 

DP  1985 

Resume  :  The  authors  present  a  snapshot  of  one  project's 

concerns  and  proposed  solutions  for  using  ada  to 
develop  system  software  for  a  distributed  damage- 
and  fault -tolerant  processing  architecture.  The 
project  Is  the  nasa-sponsored  advanced  Information 
processing  system  (alps).  The  authors  also  describe 
how  the  alps  system  software  can  be  written  In  ada 
using  a  standard  uniprocessor  runtime  support 
package.  The  system  software  provides  certain 
commonly  used  services  to  the  applications 
programmer  beyond  those  Inherent  In  the  ada  language 
definition.  In  addition.  It  provides  network 
transparency  for  interfunction  communication. 
Implementing  these  services  In  ada  raises  certain 
Issues  relating  to  the  runtime  support  package.  The 
current  strategy  for  responding  to  these  issues  is 
described  and  recommendations  are  made  for  improving 
ada  runtime  support  features. 

-29-  451107  C. INSPEC 

Tltre  Anglais  :  ULTRARELIABLE  FAULT-TOLERANT  CONTROL  SYSTEMS 
^AEROSPACE  CONTROL ! . 

Tltre  Conference:  PROCEEDINGS  OF  THE  AIAA/IEEE  6iH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  NO.  84CH-2 132-9) 

Lieu  Conference  :  BALTIMORE,  MD,  USA 
Date  conference  :  3-6  DEC.  1984 

Auteurs  :  WEBSTER  L.  D.;  SLYKHOUSE  R.  A.;  BOOTH  L.  A.  ;  CARSON 

T.  M.  ;  DAVIS  G.  J.  ; 

Affiliation  :  AMES  RES.  CENTER,  NASA,  MOFFETT  FIELD,  CA,  USA  (06); 
Type  Document  :  Conference  Paper 

Edlteur  :  AIAA,  NEW  YORK,  USA 
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Source  :  NP.  XXXV+666 ;  PP.  239-46;  REF.  9;  SPO.  IEEE;  AIAA; 

DP  1985 

Resume  ;  An  ultrarel leble  fault-tolerant  control  system 

(uftcs)  concept  is  OescrlDed  using  a  systems  design 
pnilosopny  which  allows  the  development  of  system 
structures  containing  virtually  no  common  elements. 
Common  elements  limit  achievable  system  reliability 
and  can  cause  catastrophic  loss  of  fault-tolerant 
system  function.  The  uftcs  concept  provides  the 
means  for  removing  common  system  elements  by 
permitting  the  elements  of  the  system  to  operate  as 
independent,  uncoupled  entitles,  multiple  versions 
of  the  application  program  are  run  on  dissimilar 
hardware.  Fault  tolerance  is  achieved  through  the 
use  of  static  redundancy  management. 

-30-  451102  C.INSPEC 

Tltre  Anglais  :  DEVELOPMENT  TOOLS:  CASE  STUDY  FOR  LARGE  SYSTEMS. 
Tltre  Conference:  PROCEEDINGS  OF  THE  AIAA/IEEE  6TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  M3.  84CH-2132-9) 

Lieu  Conference  :  BALTIMORE.  MD,  USA 
Date  conference  :  3-6  DEC.  1984 
Auteurs  :  HORNBACH  K. 

Affiliation  :  INSTRUM.  DIV.,  LEAR  SIEGLER.  GRAND  RAPIDS.  MI.  USA 
Type  Document  :  Conference  Paper 
Edlteur  :  AIAA.  NEW  YORK.  USA 

Source  :  NP.  XXXV+666;  PP.  167-74;  REF.  8;  SPO.  IEEE;  AIAA; 

OP  1985 

Resume  :  Software  development  tools  can  be  an  important  aid 

In  controlling  the  complexity  of  large  digital 
avionics  systems.  Tne  author  describes  the 
successful  application  of  modern  software  tools  to 
the  development  of  the  flight  management  computer 
system  for  the  boelng  737-300  aircraft.  Tools  were 
used  to  increase  productivity  and  quality  during  the 
entire  software  life  cycle.  Source  code  management 
tools  provided  thorough,  ongoing  configuration 
management  of  code.  Static  analysis  and  path 
coverage  of  the  source  aided  In  meeting  stringent 
verification  requirements.  Fourth-generation 
language  techniques  were  used  to  produce  many  of  the 
tools  cost-effectively;  and  text  formatting  tools 
were  used  to  increase  documentation  productivity. 

-31-  451101  C.INSPEC 

Tltre  Anglais  :  SOFTWARE  TRACEABILITY,  REQUIREMENTS  TESTABILITY,  AND 
AUDITING  MODEL. 

Tltre  Conference:  PROCEEDINGS  OF  THE  AIAA/IEEE  6TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE  (CAT.  NO.  84CH-2 132-9) 

Lieu  Conference  :  BALTIMORE.  MD,  USA 
Date  conference  :  3-6  DEC.  1984 
Auteurs  :  SCIORTINO  J.;  DUNNING  D. 

Affiliation  :  ARINC  RES.  CORP..  ANNAPOLIS,  MD,  USA  (02); 

Type  Document  :  Conference  Paper 

Edlteur  :  AIAA,  NEW  YORK,  USA 

Source  :  NP.  XXXV+666;  PP.  159-66;  REF.  3;  SPO.  IEEE;  AIAA; 

DP  1985 

Resume  :  Software  development  for  both  management  information 

systems  (mis)  and  embedded  computer  systems  (ecs) 
has  suffered  dramatic  cost  and  time  overruns,  has 
resulted  In  user  dissatisfaction,  and  has  often 
yielded  software  that  does  not  work  in  spite  of 
extra  time  and  money  spent.  Arlnc  research  has 
developed  a  software  traceability  tool  for  reducing 
risks  In  software  development.  This  software 
traceability,  requirements  testability,  and  auditing 
(strata)  model  is  a  microcomputer-based  tracking 
system  developed  to  support  and  automate  the 
top-down  structured  approach  to  software 
development.  A  brief  description  is  given  of  the 
environment  of  embedded  systems  development  and  of 
the  advantages  of  applying  a  tool  like  strata  to  the 
software  development  of  digital  avionics  system. 
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-32-  442868  C.INSPEC 

Tltre  Anglais  :  DIGITAL  AVIONICS  FOR  MODERN  AIRCRAFT-A  CASE  STUDY 
INTO  THE  PROBLEMS  AND  PROMISE  OF  AIRCRAFT 
ELECTRONICS. 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE  1865  NATIONAL  AEROSPACE  AND 
ELECTRONICS  CONFERENCE  NAECON  1985  (CAT.  NO. 

Lieu  Conference  :  DAYTON.  OH.  USA 
Date  conference  :  20-24  MAY  1985 
Auteurs  :  ARCHER  H.  S. 

Affiliation  :  LOCKHEED  GEORGIA  CO..  MARIETTA,  GA.  USA 
Type  Document  :  Conference  Paper 
Edlteur  :  IEEE,  NEW  YORK,  USA 

Source  :  NP.  2  VOL.  1595;  PP.  144-SI  V0L.1;  REF.  1;  SPO. 

IEEE;  AEROSP.  ELECTRON.  SYST .  SOC ;  CCCC- 
0547-3578/85/0000-0144801.00;  OP  1985 
Resume  :  with  Decreasing  static  stability  margins  and 

Increasingly  rigorous  mission  requirements,  the  role 
of  aircraft  electrons  Has  become  vital.  Tne  author 
gives  a  brief  historical  perspective  of  tne 
evolution  of  avionics  and  notes  the  harsh 
environmental  constraints  under  which  current 
avionics  must  operate.  The  case  of  spatially 
redundant  integrated  racks  composed  of  standardized 
modules  Is  made.  A  state-of-the-art  design  approach 
Is  then  presented,  followed  by  a  discussion  of  an 
advanced  system  that  will  be  typical  of  aircraft  In 
the  1990s.  The  topics  discussed  Include:  designing 
for  thermal  management,  distributed  processing, 
built-in-test  requirements,  and  redundant  systems 
for  flight-critical  applications. 

-33-  442861  C.INSPEC 

Tltre  Anglais  :  DISTRIBUTED  MEMORY  NETWORK:  AN  8  GIGABIT  FIBER  OPTIC 
TIGHTLY  COUPLED  SYSTEM. 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE  1985  NATIONAL  AEROSPACE  AND 
ELECTRONICS  CONFERENCE  NAECON  1985  (CAT.  NO. 

85CH2 189-9) 

Lieu  Conference  :  DAYTON.  OH,  USA 
Date  conference  :  20-24  MAY  1985 
Auteurs  :  FOLMAR  R.  J. 

Affiliation  :  HARRIS  CORP . ,  MELBOURNE.  FL.  USA 
Type  Document  :  Conference  Paper 
Edlteur  :  IEEE.  NEW  YORK.  USA 

Source  :  NP.  2  VOL.  1595;  PP.  91-4  VOL.l;  SPO.  IEEE;  AEROSP. 

ELECTRON.  SYST.  SOC;  CCCC- 
0547-3578/85/0000-0091801.00;  DP  1985 
Resume  :  The  distributed  memory  network  (dmn)  described  Is  an 

B-gD/s  fiber  optic,  memory  connected  local  area 
network.  It  Is  designed  for  avionic  applications  and 
vhslc  signal  processor  speeds.  System  operation, 
memory  connected  communication,  fiber  optic  data 
link  and  fault-tolerant  features  are  described.  An 
engineering  development  model  of  this  network  that 
is  currently  in  the  fabrication  phase  is  described. 

-34-  433231  C.INSPEC 

Tltre  Anglais  :  SOFTWARE  TOOLS-A  WAY  TO  CONTROL  COMPLEXITY  ON  LARGE 
SOFTWARE  PROJECTS. 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE  1985  NATIONAL  AEROSPACE  AND 
ELECTRONICS  CONFERENCE  NAECON  1985  (CAT.  NO. 

85CH2 189-9) 

Lieu  Conference  :  DAYTON,  OH,  USA 
Date  conference  :  20-24  MAY  1985 
Auteurs  :  HORNBACH  K. 

Affiliation  ;  LEAR  SIEGLER,  GRAND  RAPIDS.  MI.  U'>A 
Type  Document  :  Conference  Paper 
Edlteur  :  IEEE.  NEW  YORK.  USA 

Source  :  NP.  2  VOL.  1595;  PP.  813-20  VOL.l;  REF.  12;  SPO. 

IEEE;  AEROSP.  ELECTRON.  SYST.  SOC;  CCCC- 
0547-3578/85/0000-0813801.00;  DP  1985 
Resume  :  The  size  of  avionics  software  development  projects 

has  grown  dramatically  over  the  last  several  years. 
The  complexity  of  these  projects  has  increased  even 
faster.  The  author  analyzes  how  software  development 
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tools  c*n  be  used  to  control  the  complexity  *nd 
Improve  productivity  during  tne  development  of  large 
avionic*  systems.  Major  tool  systems  examined 
Include  source  code  configuration  management, 
problem  repo-t  database,  static  analysis  of  source 
code,  data  dictionaries,  regression  test  managers, 
methodology  automation,  and  electronic  mall.  Online 
databases  are  produced  as  a  side  effect  of  many  of 
these  tools.  When  enough  databases  are  present,  a 
'project  knowledge  base;'  emerges,  which  can  be  used 
and  extended  to  provide  additional  management  and 
tracking  Information.  These  computer-based  tool  can 
be  used  to  accurately  track  the  tens  of  thousands  of 
details  related  to  the  project,  and  to  provide 
timely  progress  feedback  to  management .  Examples 
from  an  actual  project  are  described. 

-35-  433224  C.INSPEC 

Tltre  Anglais  :  A  NEW  APPROACH  TO  ENSURING  DETERMINISTIC  PROCESSING 
IN  AN  INTEGRATED  AVIONICS  SOFTWARE  SYSTEM. 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE  1985  NATIONAL  AEROSPACE  AND 
ELECTRONICS  CONFERENCE  NAECON  1985  (CAT.  NO. 

85CH2 189-9 ) 

Lieu  Conference  :  DAYTON,  OH,  USA 
Date  conference  :  20-24  MAY  1985 
Auteurs  :  ELLIS  J.  R. 

Affiliation  :  HARRIS  CORP.,  MELBOURNE.  FL.  USA 
Type  Document  :  Conference  Paper 
Edlteur  :  IEEE.  NEW  YORK.  USA 

Source  :  NP.  2  VOL.  1595;  PP.  756-63  V0L.1;  REF.  4;  SPO. 

IEEE;  AEROSP.  ELECTRON.  SYST.  SOC;  CCCC» 
0547-3578/85/0000-0756*01.00;  DP  1985 
Resume  ;  The  traditional  approach  to  avionics  software 

systems  has  been  to  ensure  identical  time  for  each 
cycle  through  the  code  regardless  of  the  path  taken. 
This  cyclic  executive  approach  is  not  compatible 
with  future  avionics  software  with  continually 
increasing  functional  integration.  The  author 
describes  a  software  architecture  used  in  an 
integrated  avionics  software  system  for  the  agusta 
a-129  light  attack  helicopter.  The  architecture  is 
presented  as  the  executive  functions  required  for 
integrated  deterministic  and  statistical  processing 
In  a  single  computer;  it  supports  integrated  fault 
detection  for  software  and/or  hardware  failures.  The 
architecture  supports  use  of  high-order  programming 
languages,  potentially  shorter  system  development 
times  through  the  Introduction  of  greater 
development  concurrency,  and  greater  flexibility  and 
lower  costs  In  software  maintenance,  without 
sacrificing  operational  reliability. 

-36-  359807  C.INSPEC 

Tltre  Anglais  :  FAULT  TOLERANT  COMPUTER  SYSTEM  FOR  THE  A 129 
HELICOPTER. 

Auteurs  :  JOHNSON  B.  W. ;  JULICH  P.  M. 

Affiliation  :  DEPT.  OF  ELECTR.  ENG.,  VIRGINIA  UNIV. , 
CHARLOTTESVILLE.  VA.  USA 
Type  Document  :  Journal  Article 

Tltre  journal  :  IEEE  TRANS.  AEROSP.  AND  ELECTRON.  SYST.  (USA) 

Source  :  VOL. AES-21,  NO. 2;  PP .  220-9;  REF.  5;  CCCC- 

0018-9251/85/0300-0220*01.00;  DP  MARCH  1985 
Coden  :  IEARAX 

Issn  :  0018-9251 

Resume  ;  a  description  of  the  design  and  an  analysis  of  the 

fault-tolerance  characteristics  of  the  al29 
Integrated  multiplex  system  (1ms)  are  presented.  The 
al29  ims  Is  a  computer  system  designed  to  implement 
automatic  flight  control,  navigation,  system 
monitoring,  and  other  flight-critical  and 
mission-related  tasks.  The  fault-tolerance  design 
philosophy  has  been  to  Implement  the  majority  of  the 
fault  detection  and  redundancy  management  features 
in  software  as  opposed  to  hardware.  The  resulting 
system  has  been  shown,  via  a  markov  reliability 


B-41 


COMPUTING  SYSTEM  CONFIGURATIONS  FOR  HIGHLY 
INTEGRATED  GUIDANCE  AND  CONTROL  SYSTEMS 


analysis,  to  possess  Mgn  reliability  during  a 
three-hour  mission. 

*"37"  321795  C  INSPEC 

Tltre  Anglais  :  ACHIEVING  GREATER  PRODUCTIVITY  THROUGH  SOFTWARE 
TOOLS. 

Tltre  Conference:  PROCEEDINGS  OF  THE  DIGITAL  EQUIPMENT  COMPUTER  USERS 
SOCIETY  EUROPE  1984 

Lieu  Conference  :  AMSTERDAM.  NETHERLANDS 
Date  conference  :  24-28  SEPT.  1984 

Auteurs  :  HORNBACH  K. 

Affiliation  :  LEAR  SIEGLER  INSTRUM.  DIV..  GRAND  RAPIDS.  MI.  USA 
Type  Document  :  Conference  Paper 

Edlteur  :  DECUS  EUROPE,  PETIT-LANCY,  SWITZERLAND 

Source  :  NP.  VI +577;  PP .  374-85;  REF.  6;  DP  1983 

Resume  -.  While  papers  abound  on  the  theoretical  and  prototype 

usage  of  software  development  tools,  tnere  have  been 
very  few  case  studies  showing  the  integrated  use  of 
commercially  available  tools  on  large  real-world 
projects.  A  new  set  of  problems  arise  when  tools  and 
techniques  developed  for  small  projects  are  used  on 
projects  an  order  of  magnitude  larger.  This  paper 
describes  the  successful  application  of  modern  tools 
and  methodologies  to  a  very  large,  real  time 
avionics  system-what  worked,  what  didn't,  and  what 
one  would  change  If  one  could  do  It  over  again.  The 
biggest  paybacks  sometimes  came  from  unexpected 
areas;  as  did  many  of  the  problems.  Dec's  vms 
software  development  tools  and  vax  information 
architecture  provided  much  of  the  foundation. 

Conf iguratlon  management,  automation  of  structured 
analysis  and  design,  static  analysis  of  source,  and 
autoaated  documentation  are  some  examples  of  tool 
usage  examined. 

-38-  307036  C. INSPEC 

Tltre  Anglais  :  DOCUMENTATION  AND  SEPARATE  TEST  PROGRAM  DEVELOPMENT 
IS  MOST  IMPORTANT  FOR  TEST /MAINTENANCE  ^FLIGHT 
SOFTWARE ! . 

Tltre  Conference:  AGARD  CONFERENCE  PROCEEDINGS  NO.  361.  DESIGN  FOR 
TACTICAL  AVIONICS  MAINTAINABILITY  (AGARD-CP-361 ) 

Lieu  Conference  :  BRUSSELS,  BELGIUM 
Date  conference  :  7-10  MAY  1984 
Auteurs  :  GUSMANN  B.;  SANDNER  N. 

Affiliation  :  LITEF,  FREIBURG.  GERMANY  (02); 

Type  Document  .-  Conference  Paper 
Edlteur  :  AGARD.  NEUILLY-SUR-SEINE.  FRANCE 

Source  :  NP.  XI+294;  PP.  17/1-10;  DP  OCT.  1984 

Resume  :  At  lltef,  operational  flight  software  is  In  either 

the  maintenance  or  development  phase  for  various 
systems  for  transport  aircraft  and  military 
applications.  Support  software  Is  in  the  development 
and  maintenance  phase  for  the  new  tornado  main 
computer.  Most  Important  for  test  and  maintenance 
phases  are  well  defined  development  phases  with 
standardized  documentations  supported  by  computer 
based  tools.  The  lltef  software  development  is  based 
on  a  software  handbook  consisting  of  software 
guidelines,  met hods/techni dues  and  automated  tools. 
The  authors  focus  on  the  documentation  throughout 
the  lifecycle  ang  the  importance  of  Independent 
test ing. 

-39-  269712  C. INSPEC 

Tltre  Anglais  :  SOFTWARE  MAINTENANCE  WORKSHOP  RECORD  (CAT.  NO. 

83CH 1982*8 ) 

Tltre  Conference:  SOFTWARE  MAINTENANCE  WORKSHOP  RECORD  (CAT.  NO. 
83CH1982-8) 

Lieu  Conference  :  MONTEREY,  ca,  USA 

Date  conference  :  6-8  DEC.  1983 

Auteurs  :  ARNOLD  R.  S. 

Type  Document  :  Conference  Proceedings 

Edlteur  :  IEEE  COMPUT.  SOC.  PRESS.  SILVER  SPRING,  MO,  USA 

Source  :  NP.  XV+302;  SPO.  IEEE;  NBS ;  NAVAL  POSTGRADUATE 

SCHOOL;  ACM;  DP  1984 
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Isbn  :  0-8186-0510-3 

Resume  :  The  following  toolcs  were  Oealt  with:  approaches  for 

providing  maintainable  software:  tools  for  software 
maintenance;  program  evolut Ion ;  software  maintenance 
and  testing  practices;  software  and  maintenance 
management;  understanding  and  documenting  software; 
maintenance  in  a  database  environment ;  software 
maintenance  In  Sweden;  software  maintenance  in 
japan;  and  avionics  software  maintenance  case 
studies.  51  papers  were  presented,  of  which  45  are 
published  in  full  in  the  present  proceedings,  and  6 
as  abstracts  only.  Twelve  papers  that  were  not 
presented  are  also  Included  in  these  proceedings. 
Abstracts  of  individual  papers  can  be  found  under 
the  relevant  classification  codes  In  this  or  other 
issues . 

-40-  185722  C.INSPEC 

Tltre  Anglais  .  THE  SPACE  SHUTTLE  PRIMARY  COMPUTER  SYSTEM. 

Auteurs  :  SPECTOR  A.;  GIFFORD  D. 

Affiliation  :  DEPT.  OF  COMPUTER  SCI.,  CARNEGIE -MELLON  UNIV.. 

PITTSBURGH,  PA,  USA 
Type  Document  ;  Journal  Article 

Tltre  journal  :  COMMUN.  ACM  (USA) 

Source  :  VOL. 27,  NO. 9;  PP .  872-900:  REF.  5;  CCCC« 

0001-0782/84/0900-0874/75C;  DP  SEPT.  19B4 
Coden  :  CACMA2 

Issn  :  0001-0782 

Resume  :  Ibm's  federal  systems  division  is  responsible  for 

supplying  'error-free'  software  for  nasa's  space 
shuttle  program.  The  shuttle's  primary  avionics 
software  system  (pass)  is  the  highly  fault-tolerant, 
on-board  software  that  controls  most  aspects  of 
shuttle  operation.  The  on-board  system  (called  the 
dps.  for  data  processing  system)  utilizes  five 
computers,  whlcn  are  Known  as  gpcs  (general-purpose 
computers).  The  pass  resides  In  a  maximum  of  four  of 
these  at  any  one  time.  Since  the  software  needed  to 
support  an  entire  mission  would  be  too  large  to 
occupy  the  primary  memory,  it  has  been  divided  Into 
eight  overlays  that  make  up  the  operational  programs 
of  pass.  The  software  has  an  operating  system 
written  In  assembler  and  applications  written  in 
hal/s,  a  hign-order  language  developed  by 
Intermetrics  Inc.  Of  Cambridge,  massachusetts . 

-41-  153082  C.INSPEC 

Tltre  Anglais  :  A  HIGH-SPEED  MIL-STD- 1750A  CMOS/SOS  MICROPROCESSOR 
(AVIONICS  APPLICATION! . 

Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE/AIAA  5TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE 
Lieu  Conference  :  SEATTLE.  WA,  USA 
Date  conference  :  31  OCT. -3  NOV.  1983 

Auteurs  :  RASSET  T.  L. ;  HANNA  W.  A.;  WALLACE  L.  N. 

Affiliation  :  MCDONNELL  DOUGLAS  ASTRONAUTICS  CO.,  HUNTINGTON 
BEACH,  CA,  USA 

Type  Document  :  Conference  Paper 
Edlteur  :  IEEE,  NEW  YORK,  USA 

Source  :  NP.  826;  PP.  18.6/1-7;  REF.  3;  SPO.  IEEE;  CCCC- 

CH1839-0/83/0000-0085S01 .00;  OP  1983 
Resume  :  A  high-speed,  low-power,  hardened  ml l-std-l750a 

(usaf)  cmos/sos  chip  set  is  discussed.  The  chip  set 
contains  the  following  options:  timers  a  and  b; 
trigger-go  counter;  startup  roi.i  control;  and  dma 
control.  Special  elements  have  been  built  Into  the 
chip  set  to  aid  testing  and  hardware/software 
Integration.  Both  a  hardened  and  a  space-hardened 
version  of  the  chip  set  have  been  developed.  To 
support  the  chip  set,  an  Integrated  set  of  hardware 
and  software  development  tools,  including  a 
processor  monitor  system,  has  been  developed. 

-42-  135027  C.INSPEC 

Tltre  Anglais  :  PROCEEDINGS  OF  THE  IEEE/AIAA  5TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE. 
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Tltre  Conference:  PROCEEDINGS  OF  THE  IEEE/AIAA  5TH  DIGITAL  AVIONICS 
SYSTEMS  CONFERENCE 
Lieu  Conference  :  SEATTLE,  WA,  USA 

Date  conference  :  31  OCT. -3  NOV.  1983 

Type  Document  :  Conference  Proceedings 

Edlteur  :  IEEE,  NEW  YORK,  USA 

Source  :  NP.  826;  SPO.  IEEE;  DP  1983 

Resume  :  The  following  topics  are  dealt  with:  advanced 

avionics  systems;  avionics  for  v/stol  and 
rotorcraft ;  software  management;  simulation;  digital 
flight  control  systems,-  flight  software;  integrated 
communications,  navigation  and  Identification 
systems:  sensors  and  signal  processing;  data  buses; 
on-board  monitoring  and  support;  fault-tolerant 
avionics;  digital  systems;  Integrated  crew  stations; 
traffic  alert  and  collision  avoidance  systems-, 
commercial  aircraft  systems;  and  vnslc  applications. 
142  papers  were  presented,  of  which  114  are 
published  In  full  in  the  present  proceedings,  and  4 
as  abstracts  only.  Abstracts  of  Individual  papers 
can  be  found  under  the  relevant  classification  codes 
in  this  or  other  issues. 

-43“  33262  C  INSPEC 

Tltre  Anglais  :  TECHNICAL  EVALUATION  REPORT  ON  THE  GUIDANCE  AND 

CONTROL  PANEL  35TH  SYMPOSIUM  ON  ADVANCES  IN  GUIDANCE 
AND  CONTROL  SYSTEMS. 

Auteurs  .-  REDIESS  H.  A. 

Organ isme  auteur:  AGARO,  NEUILLY  SUR  SEINE,  FRANCE 

Type  Document  :  Report 

Numeros  :  RPT  AGARD-AR- 195 

Source  :  NP.  IV-M1;  DP  JULY  1983 

Resume  :  Many  significant  advances  In  optimal  control  theory, 

synthesis  techniques  and  design  methodology  have 
taken  place  since  the  last  symposium  held  in  this 
technical  area  in  1973.  The  rapidly  developing 
technologies  in  computation,  data  distribution, 
computer  aided  design  methods  and  data  basis  now 
permit  application  of  theories  and  synthesis  methods 
heretofore  Impractical.  The  increased  emphasis  on 
functional  and  performance  capability  at  reduced 
cost  suggests  application  of  technologies  and 
methods  for  more  common  use  of  information  and 
higher  levels  of  integration.  The  purpose  of  the 
meeting  was  to  review  and  discuss  all  aspects  of 
those  emerging  technologies  ranging  from  theory 
through  applications  including  aircraft,  space 
vehicles,  and  unmanned  vehicles. 


REPORT  DOCUMENTATION  PAGE 


I .  Recipient's  Reference 

2.  Originator's  Reference 

3.  Further  Reference 

4.  Security  Classification 

of  Document 

AGARD-LS- 158 

ISBN  92-835-0464-X 

UNCLASSIFIED 

5.  Originator  Advisory  Group  for  Aerospace  Research  and  Development 
North  Atlantic  Treaty  Organization 
7  rue  Ancelle,  92200  NeuiUy  sur  Seine,  France 


6.  Title 


COMPUTING  SYSTEMS  CONFIGURATION  FOR  HIGHLY  INTEGRATED 
GUIDANCE  AND  CONTROL  SYSTEMS 


7.  Presented  at 


8.  Author(s)/Editor(s) 


Various 


9.  Date 

June  1988 


1 0.  Author’s/Editor's  Address 


Various 


1 1 .  Pages 

166 


1 2.  Distribution  Statement 


This  document  is  distributed  in  accordance  with  AGARD 
policies  and  regulations,  which  are  outlined  on  the 
Outside  Back  Covers  of  all  AGARD  publications. 


13.  Keywords/Descriptors 

Missile  guidance 
Guidance  computers 
Computer  systems  programs 


Control  equipment 

Avionics 

Design 


14.  Abstract 

Modem  military  air  vehicles  have  to  comply  with  sophisticated  performance  requirements.  As  a 
result,  full  advantage  must  be  taken  of  the  rapid  advances  in  computer  hardware/software  and 
future  micro-electronics  technologies. 

New  design  and  development  strategies  must  be  implemented  in  order  to  obtain  the  overall  per¬ 
formance  benefits  offered  by  advanced  integrated  systems  for  guidance  and  control,  avionics, 
weapon  delivery  and  tactical  performance  management. 

In  a  two-day  programme  this  Lecture  Series  will  address  some  issues  which  have  demonstrated  not¬ 
able  and  outstanding  advances  in  the  field  of  computing  system  design,  design  tools  and  techniques, 
computers,  data  buses,  and  architectures.  In  particular,  the  second  day's  programme 
will  show  how  technological  advances  have  enabled  the  design  of  a  modem  computing  system  archi¬ 
tecture.  Future  trends  and  new  directions  will  be  subjects  for  round  table  discussions. 


This  Lecture  Series,  sponsored  by  the  Guidance  and  Control  Panel  of  AGARD,  has  been  imple¬ 
mented  by  the  Consultant  and  Exchange  Programme  of  AGARD. 
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New  design  and  development  strategies  must  be  New  design  and  development  strategies  must  be 

implemented  in  order  to  obtain  the  overall  performance  implemented  in  order  to  obtain  the  overall  performance 


